lack of RTTI.

llvm-svn: 94484

llvm-svn: 94378

TimeValue()::now().toEpochTime() is supposed to be the same as time(),
but it wasn't, because toEpoch subtracted PosixZeroTime, but now()
didn't add PosixZeroTime!
Add a unittest to check this works.

llvm-svn: 94178

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

llvm-svn: 92761

a single pointer (PointerIntPair) member. In "small" mode, the
pointer field is reinterpreted as a set of bits. In "large" mode,
the pointer points to a heap-allocated object.

Also, give BitVector empty and swap functions.

And, add some simple unittests for BitVector and SmallBitVector.

llvm-svn: 92730

warning: comparison between signed and unsigned integer expressions
llvm-svn: 92359

to SmallVector, and add a unit test.

llvm-svn: 92340

llvm-svn: 92328

things that occur in types.  "operands" are things that occur
in values.

llvm-svn: 92322

major bugs in long-precision conversion.

llvm-svn: 92150

will be found by argument-dependent lookup. As with the previous
commit, GCC is allowing ill-formed code.

llvm-svn: 92146

argument-dependent lookup can find it. This is another case where an
LLVM bug (not making operator<< visible) was masked by a GCC bug
(looking in the global namespace when it shouldn't).

llvm-svn: 92144

smallest-normalized-magnitude values in a given FP semantics.
Provide an APFloat-to-string conversion which I am quite ready to admit could
be much more efficient.

llvm-svn: 92126

implemented.

llvm-svn: 91963

they're available_externally broke VMKit, which was relying on the fact that
functions would only be materialized when they were first called.  We'll have
to wait for http://llvm.org/PR5737 to really fix this.

I also added a test for one of the F->isDeclaration() calls which wasn't
covered by anything else in the test suite.

llvm-svn: 91943

argument to runJITOnFunction(), which caused a null pointer dereference at
every call.

Patch by Gianluca Guida!

llvm-svn: 91939

bit more verbose, but optimize to much shorter code.

llvm-svn: 91817

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