debugging some leaks (PR5770 in particular).

llvm-svn: 91713

llvm-svn: 91626

llvm-svn: 91611

nlewycky's fix to add -rdynamic so the JIT can look symbols up in Linux builds
of the JITTests binary.

llvm-svn: 91250

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

 - This is a pretty slow / memory intensive implementation, and I will likely
   change it to an iterative model, but it works.

llvm-svn: 90447

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

fixes PR5395.

llvm-svn: 89385

llvm-svn: 89357

 - I plan on fixing/workarounding this, but until then I'd like the bots to stay
   green.

llvm-svn: 89077

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

"a" + 0.

llvm-svn: 87084

Switch to smallvector. Also fix issue with using unsigend for MaxSplit.

llvm-svn: 87068

llvm-svn: 87058

otherwise create a stub.

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

llvm-svn: 86941

by default).

llvm-svn: 86807

Also, add unittests for find_first_of and find_first_not_of.

llvm-svn: 86770

This patch forbids implicit conversion of DenseMap::const_iterator to
DenseMap::iterator which was possible because DenseMapIterator inherited
(publicly) from DenseMapConstIterator. Conversion the other way around is now
allowed as one may expect.

The template DenseMapConstIterator is removed and the template parameter
IsConst which specifies whether the iterator is constant is added to
DenseMapIterator.

Actually IsConst parameter is not necessary since the constness can be
determined from KeyT but this is not relevant to the fix and can be addressed
later.

Patch by Victor Zverovich!

llvm-svn: 86636

llvm-svn: 86606

llvm-svn: 85352

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

llvm-svn: 85330

llvm-svn: 85327

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

llvm-svn: 85149

direct inclusion edge from System to Support.

llvm-svn: 85086

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

Evan Cheng.

llvm-svn: 84967

gcc-4.4.

llvm-svn: 84902

llvm-svn: 84892

even when keys get RAUWed and deleted during its lifetime. By default the keys
act like WeakVHs, but users can pass a third template parameter to configure
how updates work and whether to do anything beyond updating the map on each
action.

It's also possible to automatically acquire a lock around ValueMap updates
triggered by RAUWs and deletes, to support the ExecutionEngine.

llvm-svn: 84890

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