| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
MCJIT on Windows requires an explicit target triple with "-elf" appended to generate objects in ELF format. The common test framework was setting up this triple, but it wasn't passed to the C API in the test.
llvm-svn: 181614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeModel: It's now possible to create an MCJIT instance with any CodeModel you like. Previously it was only possible to
create an MCJIT that used CodeModel::JITDefault.
EnableFastISel: It's now possible to turn on the fast instruction selector.
The CodeModel option required some trickery. The problem is that previously, we were ensuring future binary compatibility in
the MCJITCompilerOptions by mandating that the user bzero's the options struct and passes the sizeof() that he saw; the
bindings then bzero the remaining bits. This works great but assumes that the bitwise zero equivalent of any field is a
sensible default value.
But this is not the case for LLVMCodeModel, or its internal equivalent, llvm::CodeModel::Model. In both of those, the default
for a JIT is CodeModel::JITDefault (or LLVMCodeModelJITDefault), which is not bitwise zero.
Hence this change introduces LLVMInitializeMCJITCompilerOptions(), which will initialize the user's options struct with
defaults. The user will use this in the same way that they would have previously used memset() or bzero(). MCJITCAPITest.cpp
illustrates the change, as does the comment in ExecutionEngine.h.
llvm-svn: 180893
|
|
|
|
|
|
| |
limit.
llvm-svn: 180839
|
|
|
|
|
|
|
|
| |
Re-submitting with fix for OCaml dependency problems (removing dependency on SectionMemoryManager when it isn't used).
Patch by Fili Pizlo
llvm-svn: 180720
|
|
|
|
| |
llvm-svn: 180575
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 07f03923137a91e3cca5d7fc075a22f8c9baf33a.
Looks like it broke the valgrind bot:
http://lab.llvm.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/649
llvm-svn: 180249
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 8c31b298149ca3c3f2bbd9e8aa9a01c4d91f3d74.
It looks like this commit broke some bots:
http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/5209
llvm-svn: 180248
|
|
|
|
|
|
| |
Patch by Filip Pizlo
llvm-svn: 180229
|
|
|
|
| |
llvm-svn: 180150
|
|
|
|
| |
llvm-svn: 180146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time. This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.
Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it. On architectures with a
single bitness, the host and process triples are identical. On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.
This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.
Differential Revision: http://llvm-reviews.chandlerc.com/D254
llvm-svn: 172627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
|
|
|
| |
llvm-svn: 169250
|
|
|
|
|
|
|
|
| |
The SectionMemoryManager now supports (and requires) applying section-specific page permissions. Clients using this memory manager must call either MCJIT::finalizeObject() or SectionMemoryManager::applyPermissions() before executing JITed code.
See r168718 for changes from the previous implementation.
llvm-svn: 168721
|
|
|
|
|
|
| |
This commit is primarily here for the revision history. I'm about to move the SectionMemoryManager into the RuntimeDyld library, but I wanted to check the changes in here so people could see the differences in the updated implementation.
llvm-svn: 168718
|
|
|
|
|
|
| |
permissions after an object has been loaded.
llvm-svn: 168114
|
|
|
|
|
|
| |
invalidated before code execution.
llvm-svn: 167146
|
|
|
|
| |
llvm-svn: 167145
|
|
|
|
| |
llvm-svn: 167144
|
|
Patch by Daniel Malea.
llvm-svn: 165246
|