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

llvm-svn: 156606

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: 154312

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: 153928

llvm-svn: 153902

reflected in the LLVM IR (as a declare or something), then treat it like a data
object.

N.B. This isn't 100% correct. The ASM parser should supply more information so
that we know what type of object it is, and what attributes it should have.

llvm-svn: 153870

definition for it. In that case, we want to wait for the potential definition
before we create a symbol for it.

llvm-svn: 153859

llvm-svn: 153810

llvm-svn: 153809

llvm-svn: 153808

llvm-svn: 153807

llvm-svn: 153805

llvm-svn: 153804

llvm-svn: 153803

llvm-svn: 153802

  into the function.
* Reorder some header files.

llvm-svn: 153783

llvm-svn: 153740

Module-level ASM may contain definitions of functions and globals. However, we
were not telling the linker that these globals had definitions. As far as it was
concerned, they were just declarations.

Attempt to resolve this by inserting module-level ASM functions and globals into
the '_symbol' set so that the linker will know that they have values.

This gets us further towards our goal of compiling LLVM, but it still has
problems when linking libLTO.dylib because of the `-dead_strip' flag that's
passed to the linker.

<rdar://problem/11124216>

llvm-svn: 153638

llvm-svn: 153634

llvm-svn: 153632

llvm-svn: 153612

llvm-svn: 153598

a bunch of comments for the various functions. No intended functionality change.

llvm-svn: 153595

llvm-svn: 153567

but with a critical fix to the SelectionDAG code that optimizes copies
from strings into immediate stores: the previous code was stopping reading
string data at the first nul.  Address this by adding a new argument to
llvm::getConstantStringInfo, preserving the behavior before the patch.

llvm-svn: 149800

These are:

r149348
r149351
r149352
r149354
r149356
r149357
r149361
r149362
r149364
r149365

llvm-svn: 149470

This is the initial checkin of the basic-block autovectorization pass along with some supporting vectorization infrastructure.
Special thanks to everyone who helped review this code over the last several months (especially Tobias Grosser).

llvm-svn: 149468

update this to ConstantDataArray.  There are no tests and this isn't using the preferred functionality for ripping apart strings, so I have no way to test this.

llvm-svn: 149361

Provide source line number information.

llvm-svn: 149101

llvm-svn: 148578

file error checking. Use that to error on an unfinished cfi_startproc.

The error is not nice, but is already better than a segmentation fault.

llvm-svn: 147717

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

decrease some code indentation. No intended functional changes.

llvm-svn: 143723

llvm-svn: 143690