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

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