another stub, but then never calling the jitted function) can cause the JIT to
leave a stub in place. Judging by the comments this is a known deficiency, so
we're just not going to use AssertingVH for the StubToFunctionTy map.
Also shorten some lines longer than 80 columns.
This fixes the "make check" failure with ocaml on x86-64 linux.
llvm-svn: 70185
locks must be matched with unlocks. Also, use calloc to allocate the
block so that it is properly zero'd. Thanks to Nick Kledzik for
tracking this down.
llvm-svn: 69314
1. ConstantPoolSDNode alignment field is log2 value of the alignment requirement. This is not consistent with other SDNode variants.
2. MachineConstantPool alignment field is also a log2 value.
3. However, some places are creating ConstantPoolSDNode with alignment value rather than log2 values. This creates entries with artificially large alignments, e.g. 256 for SSE vector values.
4. Constant pool entry offsets are computed when they are created. However, asm printer group them by sections. That means the offsets are no longer valid. However, asm printer uses them to determine size of padding between entries.
5. Asm printer uses expensive data structure multimap to track constant pool entries by sections.
6. Asm printer iterate over SmallPtrSet when it's emitting constant pool entries. This is non-deterministic.
Solutions:
1. ConstantPoolSDNode alignment field is changed to keep non-log2 value.
2. MachineConstantPool alignment field is also changed to keep non-log2 value.
3. Functions that create ConstantPool nodes are passing in non-log2 alignments.
4. MachineConstantPoolEntry no longer keeps an offset field. It's replaced with an alignment field. Offsets are not computed when constant pool entries are created. They are computed on the fly in asm printer and JIT.
5. Asm printer uses cheaper data structure to group constant pool entries.
6. Asm printer compute entry offsets after grouping is done.
7. Change JIT code to compute entry offsets on the fly.
llvm-svn: 66875
allocating memory in the JIT. This is insanely inefficient, but
hey, most people implement their own memory managers anyway.
Patch by Eric Yew!
llvm-svn: 66472
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
llvm-svn: 66339
1. When the JIT is asked to remove a function, updating it's
mapping to 0, we invalidate any function stubs used only
by that function. Now, also invalidate the JIT's mapping
from the GV the stub pointed to, to the address of the GV.
2. When dlsym stubs for cross-process JIT are enabled, do not
abort just because a named function cannot be found in the
JIT's process.
3. Fix various assumptions about when it is ok to use the lazy
resolver when non-lazy JITing is enabled.
llvm-svn: 66324
This invalidates the stubs in the resolver map when they are no longer referenced,
and should the JIT memory manager ever pick up a deallocateStub interface, the
JIT could reclaim the memory for unused stubs as well.
llvm-svn: 66141
on failure to resolve it.
Do not abort on failure to resolve an external symbol when using dlsym stubs,
since the symbol may not be in the JIT's address space. Just use 0.
Allow dlsym stubs to differentiate between GlobalVars and Functions.
llvm-svn: 66050
that has not been JIT'd yet, the callee is put on a list of pending functions
to JIT. The call is directed through a stub, which is updated with the address
of the function after it has been JIT'd. A new interface for allocating and
updating empty stubs is provided.
Add support for removing the ModuleProvider the JIT was created with, which
would otherwise invalidate the JIT's PassManager, which is initialized with the
ModuleProvider's Module.
Add support under a new ExecutionEngine flag for emitting the infomration
necessary to update Function and GlobalVariable stubs after JITing them, by
recording the address of the stub and the name of the GlobalValue. This allows
code to be copied from one address space to another, where libraries may live
at different virtual addresses, and have the stubs updated with their new
correct target addresses.
llvm-svn: 64906
there.
This changes the interpreter to use libffi. After this patch, the interpreter
will barely be able to call any external functions if built on a system without
libffi installed (just enough to pass 'make check' really). But with libffi,
we can now call any function that isn't variadic or taking a struct or vector
parameter (but pointer to struct is fine). Patch by Alexei Svitkine!
llvm-svn: 63723
This requires a rebuild of 'configure' itself. I will be committing that next, but
built with the wrong version of autoconf. Somebody who has the right one, please update
it.
As a side-note, because of the way autoconf works, all built tools will link against
libffi, not just lli. If you know how to fix this, please let me know ...
llvm-svn: 62553
SingleSource/UnitTests/2007-04-25-weak.c in JIT mode. The test
now passes on systems which are able to produce a correct
reference output to compare with.
llvm-svn: 61674
