| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 66143
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 65967
|
|
|
|
| |
llvm-svn: 65895
|
|
|
|
|
|
| |
of arguments.
llvm-svn: 64999
|
|
|
|
|
|
|
| |
being called with the lock released, and this fixes a race condition
in the JIT as used by lli.
llvm-svn: 64997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
be encoded.
llvm-svn: 64600
|
|
|
|
|
|
|
| |
that already hold the lock can call an entry point that doesn't
re-acquire the lock.
llvm-svn: 63965
|
|
|
|
| |
llvm-svn: 63489
|
|
|
|
|
|
| |
does not cause the owned module to be fully materialized.
llvm-svn: 62864
|
|
|
|
|
|
| |
that's not constant whether it's "internal" or not. In a server / client environment, GV is returned in the same block of memory as code. However, the memory might not be writable.
llvm-svn: 62336
|
|
|
|
|
|
|
| |
Split Support/Registry.h into two files so that we have less to
recompile every time CommandLine.h is changed.
llvm-svn: 62312
|
|
|
|
| |
llvm-svn: 62307
|
|
|
|
| |
llvm-svn: 62279
|
|
|
|
|
|
| |
suggested by Chris.
llvm-svn: 62099
|
|
|
|
| |
llvm-svn: 61991
|
|
|
|
| |
llvm-svn: 61699
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
some overflow issues. Patch by Thomas Jablin.
llvm-svn: 60828
|
|
|
|
|
|
| |
actual function ptr instead of ptr to stub if function is already compiled.
llvm-svn: 60822
|
|
|
|
| |
llvm-svn: 60750
|
|
|
|
| |
llvm-svn: 59904
|
|
|
|
|
|
|
| |
encoded on 32 bytes, and the personality function is not encoded as
relative.
llvm-svn: 59516
|
|
|
|
|
|
| |
is one). This makes it possible to compare function pointer values in lazy compilation mode. This fixes PR3043.
llvm-svn: 59265
|
|
|
|
| |
llvm-svn: 59119
|
|
|
|
| |
llvm-svn: 59007
|
|
|
|
| |
llvm-svn: 58952
|
|
|
|
| |
llvm-svn: 58898
|
|
|
|
|
|
| |
ptr.
llvm-svn: 58897
|
|
|
|
|
|
| |
these work on externsym machine relocations.
llvm-svn: 58895
|
|
|
|
| |
llvm-svn: 58894
|
|
|
|
| |
llvm-svn: 58868
|
|
|
|
| |
llvm-svn: 58835
|
|
|
|
| |
llvm-svn: 58807
|
|
|
|
| |
llvm-svn: 58788
|
|
|
|
| |
llvm-svn: 58782
|
|
|
|
| |
llvm-svn: 58778
|
|
|
|
|
|
| |
indirect gv reference. Please don't call it lazy.
llvm-svn: 58746
|
|
|
|
|
|
|
|
| |
as the MachineCodeEmitter allocated memory. Code and data has different read / write / execution privilege requirements.
This is a short term workaround. The current solution is for the JIT memory manager to manage code and data memory separately.
llvm-svn: 58688
|
|
|
|
| |
llvm-svn: 58598
|
|
|
|
|
|
| |
doesn't want the generic constant pool to be emitted.
llvm-svn: 58475
|
|
|
|
| |
llvm-svn: 58407
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the ARM constant pool handling supercedes the standard LLVM constant
pool entirely, the JIT emitter does not allocate space for the constants,
nor initialize the memory. The constant pool is considered part of the
instruction stream.
Likewise, when resolving relocations into the constant pool, a hook into
the target back end is used to resolve from the constant ID# to the
address where the constant is stored.
For now, the support in the ARM emitter is limited to 32-bit integer. Future
patches will expand this to the full range of constants necessary.
llvm-svn: 58338
|
|
|
|
|
|
|
|
| |
variable is moved to the execution engine. The JIT calls the TargetJITInfo
to allocate thread local storage. Currently, only linux/x86 knows how to
allocate thread local global variables.
llvm-svn: 58142
|
|
|
|
|
|
| |
JITing a variable independently of a function. This lead to sharing memory memory between functions and GVs thus changing the value of a GV could change the code in execution. more details on the ML.
llvm-svn: 57900
|
|
|
|
|
|
| |
deadlock issues with java
llvm-svn: 57356
|
|
|
|
|
|
| |
in getPointerToFunction
llvm-svn: 57340
|
|
|
|
|
|
| |
Patch by Samuel Tardieu.
llvm-svn: 57291
|