Add doInitialization and doFinalization methods to ModulePass's, to allow them to be re-initialized and reused on multiple Module's.

Patch by Pedro Artigas.

llvm-svn: 168008

llvm-svn: 166248

The TargetTransform changes are breaking LTO bootstraps of clang.  I am
working with Nadav to figure out the problem, but I am reverting it for now
to get our buildbots working.

This reverts svn commits: 165665 165669 165670 165786 165787 165997
and I have also reverted clang svn 165741

llvm-svn: 166168

llvm-svn: 165997

This is a temporary hack until Bill's project to record command line options
in the LLVM IR is ready. Clang currently sets a default CPU but that isn't
recorded anywhere and it doesn't get used in the final LTO compilation.

llvm-svn: 165809

llvm-svn: 165403

llvm-svn: 163349

llvm-svn: 161530

llvm-svn: 161356

When the command line target options were removed from the LLVM libraries, LTO
lost its ability to specify things like `-disable-fp-elim'. Add this back by
adding the command line variables to the `lto' project.
<rdar://problem/12038729>

llvm-svn: 161353

This broke in r144788 when the CodeGenOpt option was moved from everywhere else
(specifically, from addPassesToEmitFile) to createTargetMachine. Since
LTOCodeGenerator wasn't passing the 4th argument, when the 4th parameter became
the 3rd, it silently continued to compile (int->bool conversion) but meant
something completely different.

This change preserves the existing (accidental) and previous (default)
semantics of the addPassesToEmitFile and restores the previous/intended
CodeGenOpt argument by passing it appropriately to createTargetMachine.

(discovered by pending changes to -Wconversion to catch constant->bool
conversions)

llvm-svn: 157705

so we don't want it to show up in the stable 3.1 interface.

While at it, add a comment about why LTOCodeGenerator manually creates the
internalize pass.

llvm-svn: 154807

Revert the 'EnableInitializing' flag. There is debate on whether we should run that pass by default in LTO.

llvm-svn: 154356

Apply the scope restrictions after parsing the command line options. There may be some which are used in that function.

llvm-svn: 154348

llvm-svn: 154306

Consider the following program:

$ cat main.c
void foo(void) { }

int main(int argc, char *argv[]) {
    foo();
    return 0;
}
$ cat bundle.c 
extern void foo(void);

void bar(void) {
     foo();
}
$ clang -o main main.c
$ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
$ nm -m bundle.so
0000000000000f40 (__TEXT,__text) external _bar
                 (undefined) external _foo (from executable)
                 (undefined) external dyld_stub_binder (from libSystem)
$ clang -o main main.c -O4
$ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
Undefined symbols for architecture x86_64:
  "_foo", referenced from:
      _bar in bundle-elQN6d.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The linker was told that the 'foo' in 'main' was 'internal' and had no uses, so
it was dead stripped.

Another situation is something like:

define void @foo() {
  ret void
}

define void @bar() {
  call asm volatile "call _foo" ...
  ret void
}

The only use of 'foo' is inside of an inline ASM call. Since we don't look
inside those for uses of functions, we don't specify this as a "use."

Get around this by not invoking the 'internalize' pass by default. This is an
admitted hack for LTO correctness.
<rdar://problem/11185386>

llvm-svn: 154124

llvm-svn: 153902

llvm-svn: 153810

llvm-svn: 153809

llvm-svn: 153808

llvm-svn: 153807

llvm-svn: 153805

llvm-svn: 153804

llvm-svn: 153803

llvm-svn: 148578

change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.

One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.

llvm-svn: 145714

materialise them in LTO.

I observed a ~0.5-1% speedup for an LTO link of opt.

llvm-svn: 143784

llvm-svn: 143502

These are strictly utilities for registering targets and components.

llvm-svn: 138450

llvm-svn: 137913

llvm-svn: 136727

but it solves a layering violation since things in Support are not supposed to
use things in Transforms.

llvm-svn: 136726

llvm-svn: 135971

InitializeX86MCInstrInfo, etc. are combined into InitializeX86TargetMC.

llvm-svn: 135812

There is still a bit more refactoring left to do in Targets. But we are now very
close to fixing all the layering issues in MC.

llvm-svn: 135611

TargetLoweringObjectFileImpl down to MCObjectFileInfo.

TargetAsmInfo is done to one last method. It's *almost* gone!

llvm-svn: 135569

(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.

llvm-svn: 135468

to MCRegisterInfo. Also initialize the mapping at construction time.

This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.

llvm-svn: 135424

llvm-svn: 135375

Rename createAsmInfo to createMCAsmInfo and move registration code to MCTargetDesc to prepare for next round of changes.

llvm-svn: 135219