| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
the Twine was used).
llvm-svn: 131612
|
|
|
|
| |
llvm-svn: 131603
|
|
|
|
|
|
| |
dealing with them in the MCJIT.
llvm-svn: 131601
|
|
|
|
|
|
|
|
| |
In particular, into EngineBuilder. This should only impact
the private API between the EE and EB classes, not external
clients, since JITCtor and MCJITCtor are both protected members.
llvm-svn: 131317
|
|
|
|
|
|
|
| |
This prepares for making JITCtor/MCJITCtor take a
TargetMachine* directly from clients like EngineBuilder.
llvm-svn: 131316
|
|
|
|
| |
llvm-svn: 131234
|
|
|
|
|
|
| |
Please ensure the build is clean and tests are passing when recommitting.
llvm-svn: 131044
|
|
|
|
|
|
| |
Forgot to `svn rm` these in revisions 131025 / 131029.
llvm-svn: 131030
|
|
|
|
|
|
|
|
| |
In particular, into EngineBuilder. This should only impact
the private API between the EE and EB classes, not external
clients, since JITCtor and MCJITCtor are both protected members.
llvm-svn: 131026
|
|
|
|
|
|
|
| |
This prepares for making JITCtor/MCJITCtor take a
TargetMachine* directly from clients like EngineBuilder.
llvm-svn: 131025
|
|
|
|
| |
llvm-svn: 129973
|
|
|
|
| |
llvm-svn: 129445
|
|
|
|
|
|
|
| |
Teach 32-bit section loading to use the Memory Manager interface, just like
the 64-bit loading does. Tidy up a few other things here and there.
llvm-svn: 129138
|
|
|
|
|
|
|
|
|
|
| |
Start teaching the runtime Dyld interface to use the memory manager API
for allocating space. Rather than mapping directly into the MachO object,
we extract the payload for each object and copy it into a dedicated buffer
allocated via the memory manager. For now, just do Segment64, so this works
on x86_64, but not yet on ARM.
llvm-svn: 128973
|
|
|
|
| |
llvm-svn: 128959
|
|
|
|
| |
llvm-svn: 128856
|
|
|
|
|
|
|
|
|
|
|
| |
The JITMemory manager references LLVM IR constructs directly, while the
runtime Dyld works at a lower level and can handle objects which may not
originate from LLVM IR. Introduce a new layer for the memory manager to
handle the interface between them. For the MCJIT, this layer will be almost
entirely simply a call-through w/ translation between the IR objects and
symbol names.
llvm-svn: 128851
|
|
|
|
| |
llvm-svn: 128485
|
|
|
|
|
|
|
|
| |
The ExecutionEngine constructor already added the module, so there's no
need to call addModule() directly. Doing so causes a double-free of the
Module at program termination.
llvm-svn: 128171
|
|
|
|
| |
llvm-svn: 128160
|
|
|
|
| |
llvm-svn: 128095
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support argument passing simple, common, prototypes directly. More
complicated scenarios will require building up a stub function, which the
MC-JIT isn't set up to handle yet.
Add Intercept.cpp, which is just a copy from ExecutionEngine/JIT for now,
to handle looking looking up external symbol names. This probably more
properly belongs as part of RuntimeDyld. It'll migrate there as things
flesh out more fully.
llvm-svn: 128090
|
|
|
|
| |
llvm-svn: 128077
|
|
|
|
|
|
|
|
| |
Lots of cleanup to make the interfaces prettier, use the JITMemoryManager,
handle multiple functions and modules, etc.. This gets far enough that
the MCJIT compiles and runs code, though.
llvm-svn: 128052
|
|
|
|
| |
llvm-svn: 127918
|
|
|
|
|
|
|
|
|
|
|
| |
Proof-of-concept code that code-gens a module to an in-memory MachO object.
This will be hooked up to a run-time dynamic linker library (see: llvm-rtdyld
for similarly conceptual work for that part) which will take the compiled
object and link it together with the rest of the system, providing back to the
JIT a table of available symbols which will be used to respond to the
getPointerTo*() queries.
llvm-svn: 127916
|
|
|
|
| |
llvm-svn: 120298
|
|
llvm-svn: 119509
|