Patch by nobled <nobled@dreamwidth.org>

llvm-svn: 154772

Thanks to Pino Toscano for the patch

llvm-svn: 154500

ConstantFP::get(Type*, double) is unreliably host-specific:
it can't handle a type like PPC128 on an x86 host. It even
has a comment to that effect: "This should only be used for
simple constant values like 2.0/1.0 etc, that are
known-valid both as host double and as the target format."

Instead, use APFloat. While we're at it, randomize the floating
point value more thoroughly; it was previously limited
to the range 0 to 2**19 - 1.

PR12451.

llvm-svn: 154446

LangRef.html says:
"There are no arrays, vectors or constants of this type."

This was hitting assertions when passing the -generate-x86-mmx
option.

PR12452.

llvm-svn: 154445

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

optimizations which are valid for position independent code being linked
into a single executable, but not for such code being linked into
a shared library.

I discussed the design of this with Eric Christopher, and the decision
was to support an optional bit rather than a completely separate
relocation model. Fundamentally, this is still PIC relocation, its just
that certain optimizations are only valid under a PIC relocation model
when the resulting code won't be in a shared library. The simplest path
to here is to expose a single bit option in the TargetOptions. If folks
have different/better designs, I'm all ears. =]

I've included the first optimization based upon this: changing TLS
models to the *Exec models when PIE is enabled. This is the LLVM
component of PR12380 and is all of the hard work.

llvm-svn: 154294

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

Patch by Bernard Cafarelli!

llvm-svn: 153965

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

Make MCInstrInfo available to the MCInstPrinter. This will be used to remove getInstructionName and the static data it contains since the same tables are already in MCInstrInfo.

llvm-svn: 153860

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

1. The main works will made in the RuntimeDyLdImpl with uses the ObjectFile class. RuntimeDyLdMachO and RuntimeDyLdELF now only parses relocations and resolve it. This is allows to make improvements of the RuntimeDyLd more easily. In addition the support for COFF can be easily added.

2. Added ARM relocations to RuntimeDyLdELF.

3. Added support for stub functions for the ARM, allowing to do a long branch.

4. Added support for external functions that are not loaded from the object files, but can be loaded from external libraries. Now MCJIT can correctly execute the code containing the printf, putc, and etc.

5. The sections emitted instead functions, thanks Jim Grosbach. MemoryManager.startFunctionBody() and MemoryManager.endFunctionBody() have been removed.
6. MCJITMemoryManager.allocateDataSection() and MCJITMemoryManager. allocateCodeSection() used JMM->allocateSpace() instead of JMM->allocateCodeSection() and JMM->allocateDataSection(), because I got an error: "Cannot allocate an allocated block!" with object file contains more than one code or data sections.

llvm-svn: 153754

llvm-svn: 153740

llvm-svn: 153701

Added ExecutionEngine/MCJIT tests.

llvm-svn: 153694

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

llvm-svn: 153598

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

llvm-svn: 153595

llvm-svn: 153567

This should unbreak the msvc build.

llvm-svn: 153329

Patch from Mageia!

llvm-svn: 153324

llvm-svn: 153307