While making lld build under the tools directory I decided to refactor how this
works.

There is now a macro, add_llvm_external_project, which takes the name of the
expected subdirectory. This sets up two CMake options.

 * LLVM_EXTERNAL_${NAME}_SOURCE_DIR
     This is the path to the source. It defaults to
     ${CMAKE_CURRENT_SOURCE_DIR}/${name}.
 * LLVM_EXTERNAL_${NAME}_BUILD
     Enable and disable building the tool as part of LLVM.

I chose LLVM_EXTERNAL_${NAME} as a prefix so they all show up together in the
GUI.

llvm-svn: 155654

llvm-svn: 155536

llvm-ld is no longer useful and causes confusion and so it is being removed.

* Does not work very well on Windows because it must call a gcc like driver to
  assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
  ld, or fully replaced by Clang.

I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.

llvm-svn: 155147

backend flags in TargetOptions.h into their own class in r145714.

llvm-svn: 154993

llvm-svn: 154959

Add -disassemble support for -show-inst and -show-encode capability llvm-mc. Also refactor so all MC paraphernalia are created once for all uses as much as possible. 

The test change is to account for the fact that the default disassembler behaviour has changed with regards to specifying the assembly syntax to use.

llvm-svn: 154809

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

Make member variables of AsmToken private. Remove unnecessary forward declarations. Remove an unnecessary include.

llvm-svn: 154775

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