llvm/test/Makefile, branch release_27

Try r96559 for the third time. This time the shared library is only built if

2010-02-25T06:34:33Z

--enable-shared is passed to configure. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97119 91177308-0d34-0410-b5e6-96231b3b80d8

Roll back r96959 again.

2010-02-23T20:53:37Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96981 91177308-0d34-0410-b5e6-96231b3b80d8

Roll r96559 forward again, adding libLLVM-2.7svn.so to LLVM. This links 3 of

2010-02-23T18:10:07Z

the examples shared to make sure the shared library keeps working. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96959 91177308-0d34-0410-b5e6-96231b3b80d8

Eliminate llvmgcc_version testing variable.

2010-02-23T07:56:28Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96908 91177308-0d34-0410-b5e6-96231b3b80d8

Kill unused llvmgccmajvers testing variable.

2010-02-23T07:56:18Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96906 91177308-0d34-0410-b5e6-96231b3b80d8

Roll back the shared library, r96559. It broke two darwins and arm, mysteriously.

2010-02-18T04:43:02Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96569 91177308-0d34-0410-b5e6-96231b3b80d8

Add a shared library for LLVM, named libLLVM2.7svn.(so|dylib), and add an

2010-02-18T02:36:02Z

--enable-shared configure flag to have the tools linked shared. (2.7svn is just $(LLVMVersion) so it'll change to "2.7" in the release.) Always link the example programs shared to test that the shared library keeps working. On my mac laptop, Debug libLLVM2.7svn.dylib is 39MB, and opt (for example) is 16M static vs 440K shared. Two things are less than ideal here: 1) The library doesn't include any version information. Since we expect to break the ABI with every release, this shouldn't be much of a problem. If we do release a compatible 2.7.1, we may be able to hack its library to work with binaries compiled against 2.7.0, or we can just ask them to recompile. I'm hoping to get a real packaging expert to look at this for the 2.8 release. 2) llvm-config doesn't yet have an option to print link options for the shared library. I'll add this as a subsequent patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96559 91177308-0d34-0410-b5e6-96231b3b80d8

Revert the test from r88984. It relies on being able to mmap 16GB of

2009-11-16T23:32:30Z

address space (though it only uses a small fraction of that), and the buildbots disallow that. Also add a comment to the Makefile's ulimit line warning future developers that changing it won't work. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88994 91177308-0d34-0410-b5e6-96231b3b80d8

Make X86-64 in the Large model always emit 64-bit calls.

2009-11-16T22:41:33Z

The large code model is documented at http://www.x86-64.org/documentation/abi.pdf and says that calls should assume their target doesn't live within the 32-bit pc-relative offset that fits in the call instruction. To do this, we turn off the global-address->target-global-address conversion in X86TargetLowering::LowerCall(). The first attempt at this broke the lazy JIT because it can separate the movabs(imm->reg) from the actual call instruction. The lazy JIT receives the address of the movabs as a relocation and needs to record the return address from the call; and then when that call happens, it needs to patch the movabs with the newly-compiled target. We could thread the call instruction into the relocation and record the movabs<->call mapping explicitly, but that seems to require at least as much new complication in the code generator as this change. To fix this, we make lazy functions _always_ go through a call stub. You'd think we'd only have to force lazy calls through a stub on difficult platforms, but that turns out to break indirect calls through a function pointer. The right fix for that is to distinguish between calls and address-of operations on uncompiled functions, but that's complex enough to leave for someone else to do. Another attempt at this defined a new CALL64i pseudo-instruction, which expanded to a 2-instruction sequence in the assembly output and was special-cased in the X86CodeEmitter's emitInstruction() function. That broke indirect calls in the same way as above. This patch also removes a hack forcing Darwin to the small code model. Without far-call-stubs, the small code model requires things of the JITMemoryManager that the DefaultJITMemoryManager can't provide. Thanks to echristo for lots of testing! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88984 91177308-0d34-0410-b5e6-96231b3b80d8

Two small fixes for site.exp for cmake.

2009-11-08T09:29:52Z

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86453 91177308-0d34-0410-b5e6-96231b3b80d8