defined in the test, and I don't have time tonight to figure it out.

llvm-svn: 91209

supported by emitGlobals, but I don't have a test case for that.

llvm-svn: 91208

make far calls work.

llvm-svn: 89733

way for each TargetJITInfo subclass to allocate its own stubs. This
means stubs aren't as exactly-sized anymore, but it lets us get rid of
TargetJITInfo::emitFunctionStubAtAddr(), which lets ARM and PPC
support the eager JIT, fixing http://llvm.org/PR4816.

* Rename the JITEmitter's stub creation functions to describe the kind
of stub they create. So far, all of them create lazy-compilation
stubs, but they sometimes get used when far-call stubs are needed.
Fixing http://llvm.org/PR5201 will involve fixing this.

llvm-svn: 89715

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.

llvm-svn: 88994

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!

llvm-svn: 88984

llvm-svn: 88794

emitFunctionStubAtAddr.

llvm-svn: 88708

otherwise create a stub.

Add a test to make sure we don't create extraneous stubs.

llvm-svn: 86941

by default).

llvm-svn: 86807

llvm-svn: 86606

llvm-svn: 85352

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

llvm-svn: 85254

being destroyed. This allows users to run global optimizations like globaldce
even after some functions have been jitted.

This patch also removes the Function* parameter to
JITEventListener::NotifyFreeingMachineCode() since it can cause that to be
called when the Function is partially destroyed. This change will be even more
helpful later when I think we'll want to allow machine code to actually outlive
its Function.

llvm-svn: 85182

compiled.

When functions are compiled, they accumulate references in the JITResolver's
stub maps. This patch removes those references when the functions are
destroyed.  It's illegal to destroy a Function when any thread may still try to
call its machine code.

This patch also updates r83987 to use ValueMap instead of explicit CallbackVHs
and fixes a couple "do stuff inside assert()" bugs from r84522.

llvm-svn: 84975

JITEmitter.

I'm gradually making Functions auto-remove themselves from the JIT when they're
destroyed. In this case, the Function needs to be removed from the JITEmitter,
but the map recording which Functions need to be removed lived behind the
JITMemoryManager interface, which made things difficult.

This patch replaces the deallocateMemForFunction(Function*) method with a pair
of methods deallocateFunctionBody(void *) and deallocateExceptionTable(void *)
corresponding to the two startFoo/endFoo pairs.

llvm-svn: 84651

llvm-svn: 84603

llvm-svn: 84595

llvm-svn: 84482

llvm-svn: 84186

llvm-svn: 84128

4406. Patch by Nick Lewycky!

llvm-svn: 84032

GlobalValue is destroyed.  Function destruction still leaks machine code and
can crash on leaked stubs, but this is some progress.

llvm-svn: 83987

mappings, which could cause errors and assert-failures.  This patch fixes that,
adds a test, and refactors the global-mapping-removal code into a single place.

llvm-svn: 83678

llvm-svn: 83401

check-lit` on both x86-64 Linux and x86-32 Darwin.

llvm-svn: 83353

llvm-svn: 78948

address from the reverse mapping, and add a test that this works now.

llvm-svn: 78127

llvm-svn: 77730

llvm-svn: 77516

Revert the ConstantInt constructors back to their 2.5 forms where possible, thanks to contexts-on-types.  More to come.

llvm-svn: 77011

llvm-svn: 76904

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

 - Reid, please check, I'm not sure if this is what was intended.

llvm-svn: 76286

Also a test commit.

llvm-svn: 76276

llvm-svn: 75703