Now we can remove RuntimeDyld from the LLVM_LINK_COMPONENTS of
tools/lli. CMakeLists.txt LLVM_LINK_COMPONENTS shall not differ from
its companion Makefile LINK_COMPONENTS.

llvm-svn: 128069

Also perform the required dark rituals and sacrifices to placate the buildbot
spirits. We shall see if they are appeased...

llvm-svn: 128067

Proof-of-concept code that code-gens a module to an in-memory MachO object.
This will be hooked up to a run-time dynamic linker library (see: llvm-rtdyld
for similarly conceptual work for that part) which will take the compiled
object and link it together with the rest of the system, providing back to the
JIT a table of available symbols which will be used to respond to the
getPointerTo*() queries.

llvm-svn: 127916

llvm-svn: 120298

llvm-svn: 119589

llvm-svn: 119509

llvm-svn: 119508

llvm-svn: 118953

 - Also, switch tests to not using llvm-as. They run 20% faster now, not that it matters.

llvm-svn: 118952

llvm-svn: 117095

This reverts commit r113632

Conflicts:

	cmake/modules/AddLLVM.cmake

llvm-svn: 113819

llvm-svn: 113632

they hit the rest of the system.

llvm-svn: 112344

llvm-svn: 101365

characters long.

llvm-svn: 101336

llc.cpp also defined these flags, meaning that when I linked all of LLVM's
libraries into a single shared library, llc crashed on startup with duplicate
flag definitions.  This patch passes them through the EngineBuilder into
JIT::selectTarget().

llvm-svn: 95390

Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.

Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods.  The bindings to
other languages still use the ModuleProvider concept.  It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.

Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.

llvm-svn: 94686

llvm-svn: 94378

missing ones are libsupport, libsystem and libvmcore.  libvmcore is
currently blocked on bugpoint, which uses EH.  Once it stops using
EH, we can switch it off.

This #if 0's out 3 unit tests, because gtest requires RTTI information.
Suggestions welcome on how to fix this.

llvm-svn: 94164

against both 2.6 and HEAD.  The default is still changed to eager jitting.

llvm-svn: 85330

http://llvm.org/PR5184, and beef up the comments to describe what both options
do and the risks of lazy compilation in the presence of threads.

llvm-svn: 85295

default and didn't work anyway.

llvm-svn: 84720

Add a CodeGenOpt::Less level to match -O1. It'll be used by clients which do not want post-regalloc scheduling.

llvm-svn: 84272

forcing them down into various .cpp files.

This change also:
1. Renames TimeValue::toString() and Path::toString() to ::str()
   for similarity with the STL.
2. Removes all stream insertion support for sys::Path, forcing
   clients to call .str().
3. Removes a use of Config/alloca.h from bugpoint, using smallvector
   instead.
4. Weans llvm-db off <iostream>

sys::Path really needs to be gutted, but I don't have the desire to
do it at this point.

llvm-svn: 79869

llvm-svn: 78948

llvm-svn: 78133

bots like the BumpPtrAllocator changes.

llvm-svn: 76902

Reverting r76825 and r76828, since they caused clang runtime errors and some build failure involving memset.

llvm-svn: 76838

out of memory, and also make the default memory manager allocate more memory
when it runs out.

Also, switch function stubs and global data over to using the BumpPtrAllocator.

This makes it so the JIT no longer mmaps (or the equivalent on Windows) 16 MB
of memory, and instead allocates in 512K slabs.  I suspect this size could go
lower, especially on embedded platforms, now that more slabs can be allocated.

llvm-svn: 76828

 - Otherwise we get two regressions in llvm-test for applications which run out
   of space.

 - Once the JIT memory manager is improved, this can be switched back.

llvm-svn: 76291

Also a test commit.

llvm-svn: 76276

processing.

llvm-svn: 75888

To simplify the upcoming context-on-type change, switch all command line tools to using the default global context for now.

This will let us to hardwire stuff to the global context in the short term while the API is sorted out.

llvm-svn: 75846

llvm-svn: 75791

library to tell it the addresses of JITted functions.  For a
particular program, this changes the opreport -l output from:

samples %    image name        symbol name
48182  98.9729 anon (tgid:19412 range:0x7f12ccaab000-0x7f12cdaab000) anon (tgid:19412 range:0x7f12ccaab000-0x7f12cdaab000)
11     0.0226  libstdc++.so.6.0.9    /usr/lib/libstdc++.so.6.0.9

to:

samples %    image name        symbol name
24565  60.7308 19814.jo        fib_left
15365  37.9861 19814.jo        fib_right
22     0.0544  ld-2.7.so       do_lookup_x

llvm-svn: 75279

by Eric Rannaud!

llvm-svn: 74930

llvm-svn: 74770

llvm-svn: 74640

Add a pointer to the owning LLVMContext to Module.  This requires threading LLVMContext through a lot
of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.

Patches for Clang and LLVM-GCC to follow.

llvm-svn: 74614

emitted or the machine code for a function is freed.  Chris mentioned that we
may also want a notification when a stub is emitted, but that'll be a future
change.  I intend to use this to tell oprofile where functions are emitted and
what lines correspond to what addresses.

llvm-svn: 74157