summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/MCJIT/MCJIT.h
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r196639 while I investigate a bot failure.Lang Hames2013-12-071-6/+2
| | | | llvm-svn: 196641
* Add support for archives and object file caching under MCJIT.Lang Hames2013-12-071-2/+6
| | | | | | Patch by Andy Kaylor, with minor edits to resolve merge conflicts. llvm-svn: 196639
* Replaced non-ASCII character.Yaron Keren2013-10-241-1/+1
| | | | llvm-svn: 193324
* Optimizing MCJIT module state trackingAndrew Kaylor2013-10-241-22/+122
| | | | | | Patch co-developed with Yaron Keren. llvm-svn: 193291
* FIXME comment shouldn't have been doxygen styleAndrew Kaylor2013-10-211-1/+1
| | | | llvm-svn: 193131
* Improving MCJIT/RuntimeDyld thread safetyAndrew Kaylor2013-10-211-4/+0
| | | | llvm-svn: 193094
* Added comments from Andrew Kaylor.Yaron Keren2013-10-191-0/+21
| | | | llvm-svn: 193033
* Adding support for deregistering EH frames with MCJIT.Andrew Kaylor2013-10-161-0/+6
| | | | | | Patch by Yaron Keren llvm-svn: 192753
* Adding multiple object support to MCJIT EH frame handlingAndrew Kaylor2013-10-111-2/+2
| | | | llvm-svn: 192504
* Adding support and tests for multiple module handling in lliAndrew Kaylor2013-10-041-0/+5
| | | | llvm-svn: 191938
* This threads SectionName through the allocateCodeSection/allocateDataSection ↵Filip Pizlo2013-10-021-4/+5
| | | | | | | | | | | | | | | | | | APIs, both in C++ and C land. It's useful for the memory managers that are allocating a section to know what the name of the section is. At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about what each allocation is for. This allows clients that supply their own memory managers to do this. Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM client. This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM. I'm assuming that it's safe to change the C++ API because that API is allowed to change. I'm assuming that it's safe to change the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory management C API). llvm-svn: 191804
* Adding multiple module support for MCJIT.Andrew Kaylor2013-10-011-9/+89
| | | | | | | | Tests to follow. PIC with small code model and EH frame handling will not work with multiple modules. There are also some rough edges to be smoothed out for remote target support. llvm-svn: 191722
* Minor changes to the MCJITTest unittests to use the correct API for finalizingDavid Tweed2013-05-171-0/+7
| | | | | | | the JIT object (including XFAIL an ARM test that now needs fixing). Also renames internal function for consistency. llvm-svn: 182085
* SectionMemoryManager shouldn't be a JITMemoryManager. Previously, the Filip Pizlo2013-05-141-1/+1
| | | | | | | | | | | | | | | | | EngineBuilder interface required a JITMemoryManager even if it was being used to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager. Consequently, the SectionMemoryManager, which is meant for MCJIT, derived from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager methods that weren't relevant to the MCJIT. This patch fixes the situation: it teaches the EngineBuilder that RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if we're using the MCJIT. This allows us to remove the stub methods from SectionMemoryManager, and make SectionMemoryManager a direct subtype of RTDyldMemoryManager. llvm-svn: 181820
* Re-enabling MCJIT object caching with memory leak fixedAndrew Kaylor2013-04-251-2/+12
| | | | llvm-svn: 180575
* Revert "Adding object caching support to MCJIT"Rafael Espindola2013-04-251-12/+2
| | | | | | | | | | 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
* Adding object caching support to MCJITAndrew Kaylor2013-04-231-2/+12
| | | | llvm-svn: 180146
* Sort includes for all of the .h files under the 'lib' tree. These wereChandler Carruth2012-12-041-1/+1
| | | | | | | | | | missed in the first pass because the script didn't yet handle include guards. Note that the script is now able to handle all of these headers without manual edits. =] llvm-svn: 169224
* Add interface for object-based JIT events.Andrew Kaylor2012-11-061-0/+8
| | | | | | This patch adds the interface to expose events from MCJIT when an object is emitted or freed and implements the MCJIT functionality to send those events. The IntelJITEventListener implementation is left empty for now. It will be fleshed out in a future patch. llvm-svn: 167475
* Add a method to indicate section address re-assignment is finished.Andrew Kaylor2012-11-051-0/+2
| | | | | | Prior to this patch RuntimeDyld attempted to re-apply relocations every time reassignSectionAddress was called (via MCJIT::mapSectionAddress). In addition to being inefficient and redundant, this led to a problem when a section was temporarily moved too far away from another section with a relative relocation referencing the section being moved. To fix this, I'm adding a new method (finalizeObject) which the client can call to indicate that it is finished rearranging section addresses so the relocations can safely be applied. llvm-svn: 167400
* Clean-up of memory buffer and object ownership model in MCJITAndrew Kaylor2012-10-021-6/+3
| | | | llvm-svn: 165053
* Better const handling for RuntimeDyld and MCJIT.Jim Grosbach2012-09-131-1/+2
| | | | | | mapSectionAddress() wasn't consistent. llvm-svn: 163843
* MCJIT: Tidy up the constructor.Jim Grosbach2012-08-211-2/+2
| | | | | | | | | The MCJIT doesn't need or want a TargetJITInfo. That's vestigal from the old JIT, so just remove it. rdar://12119347 llvm-svn: 162280
* Enable lazy compilation in MCJITAndrew Kaylor2012-08-071-6/+13
| | | | llvm-svn: 161438
* Move getPointerToNamedFunction() from JIT/MCJIT to JITMemoryManager.Danil Malyshev2012-03-281-0/+1
| | | | llvm-svn: 153607
* Revert a series of commits to MCJIT to get the build working in CMakeChandler Carruth2012-03-221-1/+0
| | | | | | | | | | | | | | | (and hopefully on Windows). The bots have been down most of the day because of this, and it's not clear to me what all will be required to fix it. The commits started with r153205, then r153207, r153208, and r153221. The first commit seems to be the real culprit, but I couldn't revert a smaller number of patches. When resubmitting, r153207 and r153208 should be folded into r153205, they were simple build fixes. llvm-svn: 153241
* Based on this discussion: ↵Danil Malyshev2012-03-211-0/+1
| | | | | | | | | http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120305/138477.html 1. Declare a virtual function getPointerToNamedFunction() in JITMemoryManager 2. Move the implementation of getPointerToNamedFunction() form JIT/MCJIT to DefaultJITMemoryManager. llvm-svn: 153205
* ExecutionEngine interface to re-map addresses for engines that support it.Jim Grosbach2012-01-161-0/+8
| | | | llvm-svn: 148264
* A small re-factored JIT/MCJIT::getPointerToNamedFunction(), so it could be ↵Danil Malyshev2012-01-051-2/+2
| | | | | | called with the base class. llvm-svn: 147610
* ExecutionEngine: refactor interfaceDylan Noblesmith2011-12-121-3/+1
| | | | | | | | The OptLevel is now redundant with the TargetMachine*. And selectTarget() isn't really JIT-specific and could probably get refactored into one of the lower level libraries. llvm-svn: 146355
* ExecutionEngine: push TargetMachine creation into clients (v2)Dylan Noblesmith2011-05-131-4/+1
| | | | | | | | 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
* ExecutionEngine: fix JIT/MCJIT selectTarget() duplication (v2)Dylan Noblesmith2011-05-131-7/+0
| | | | | | | This prepares for making JITCtor/MCJITCtor take a TargetMachine* directly from clients like EngineBuilder. llvm-svn: 131316
* Revert ExecutionEngine patches, they either failed to build or broke unit tests.Jakob Stoklund Olesen2011-05-071-1/+11
| | | | | | Please ensure the build is clean and tests are passing when recommitting. llvm-svn: 131044
* ExecutionEngine: push TargetMachine creation into clientsDylan Noblesmith2011-05-061-4/+1
| | | | | | | | 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
* ExecutionEngine: fix JIT/MCJIT selectTarget() duplicationDylan Noblesmith2011-05-061-7/+0
| | | | | | | This prepares for making JITCtor/MCJITCtor take a TargetMachine* directly from clients like EngineBuilder. llvm-svn: 131025
* Layer the memory manager between the JIT and the runtime Dyld.Jim Grosbach2011-04-041-1/+2
| | | | | | | | | | | 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
* Add simple arg passing to MC-JIT and support for exit() call.Jim Grosbach2011-03-221-0/+10
| | | | | | | | | | | | | 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
* Hook up the MCJIT to the RuntimeDyld library.Jim Grosbach2011-03-221-0/+3
| | | | | | | | 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
* Beginnings of MC-JIT code generation.Jim Grosbach2011-03-181-1/+20
| | | | | | | | | | | 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
* MCJIT: Stub out MCJIT implementation, still doesn't do anything useful.Daniel Dunbar2010-11-171-0/+68
llvm-svn: 119509
OpenPOWER on IntegriCloud