now handle far calls (i.e., beyond the 30-bit limit in call instructions).
* As a side-effect, this allows us to unify and clean up the mmap() call and
code around it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7381 91177308-0d34-0410-b5e6-96231b3b80d8
This us used by bugpoint -- when code is compiled to a shared object to be
JITted, it must use the JIT's lazy resolution method to find function addresses,
because some functions will not be available at .so load time, as they are in
the bytecode file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7363 91177308-0d34-0410-b5e6-96231b3b80d8
* Setting ENABLE_X86_JIT or ENABLE_SPARC_JIT on the `make' command-line will
force the inclusion of that JIT on a different architecture
* If neither JIT is enabled (e.g., compiling on a different architecture), the
-march option will not be available to LLI.
* As a side effect of the $ARCH variable, the Sparc LLI can now link just a bit
faster by not including the x86 library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7070 91177308-0d34-0410-b5e6-96231b3b80d8
(We're already talking about autoconf'ing this, so I'm assuming this hack
will be short-lived...I just don't want it to get lost in my working files.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6761 91177308-0d34-0410-b5e6-96231b3b80d8
The JIT is designed to code-generate a function at-a-time. That means that any
pass can only make local changes to its function. Period.
Because the Sparc PreSelection pass claims to be a BasicBlock pass while adding
globals to the Module, it cannot be run with the other passes, because by this
time, the globals have been output already by the JIT, and the addresses of any
globals appearing AFTER this point are not recognized.
However, the PreSelection pass is a requirement for correctness in the Sparc
codegen path, so it MUST be run.
::: HACK ALERT ::: HACK ALERT ::: HACK ALERT ::: HACK ALERT ::: HACK ALERT :::
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6650 91177308-0d34-0410-b5e6-96231b3b80d8
laid out closer to the VM so that calls to library functions (e.g. puts()) and
callback (e.g. JITResolver::CompilationCallback) fit into 30 bits of the call
instruction.
* Abort if architecture is not yet supported (not X86 or Sparc) because it
likely requires a different set of parameters to mmap() .
* Stop using hard-coded values for page size; use sysconf(_SC_PAGESIZE) instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6610 91177308-0d34-0410-b5e6-96231b3b80d8
* No more createX86Emitter() vs. createSparcEmitter() -- there can be only one
* As a result, the memory management semantics must be handled according to
platform -- the parameters to mmap() are particularly sensitive to the host
architecture.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6527 91177308-0d34-0410-b5e6-96231b3b80d8
flags before. Save them in a temporary variable, then restore them from the
temporary after creating the new constant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6520 91177308-0d34-0410-b5e6-96231b3b80d8
Modify new MachineOperand so that its flags match the old MachineOperand's
flags, for the flags that matter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6513 91177308-0d34-0410-b5e6-96231b3b80d8
`lli -march=x86' or `lli -march=sparc' will forcefully select the JIT even on a
different platform. Running lli without the -march option will select the JIT
for the platform that it's currently running on.
Pro: can test Sparc JIT (debug printing mode) on X86 -- faster to compile/link
LLVM source base to test changes.
Con: Linking lli on x86 now pulls in all the Sparc libs -> longer link time
(but X86 can bear it, right?)
In the future, perhaps this should be a ./configure option to enable/disable
target JITting...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6360 91177308-0d34-0410-b5e6-96231b3b80d8
