summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 80-col fix.Eric Christopher2011-04-221-1/+1
| | | | llvm-svn: 129973
* MCJIT relocation resolution.Jim Grosbach2011-04-131-0/+2
| | | | llvm-svn: 129445
* Layer the memory manager between the JIT and the runtime Dyld.Jim Grosbach2011-04-041-4/+7
| | | | | | | | | | | 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
* Instantiate a JITMemoryManager for MCJIT DyldJim Grosbach2011-03-291-1/+1
| | | | llvm-svn: 128485
* Fix double-free of Module.Jim Grosbach2011-03-231-1/+0
| | | | | | | | 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
* Make sure to report any errors from the runtime dyld.Jim Grosbach2011-03-231-1/+2
| | | | llvm-svn: 128160
* Add simple arg passing to MC-JIT and support for exit() call.Jim Grosbach2011-03-221-4/+104
| | | | | | | | | | | | | 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
* Fix comment in header.Eric Christopher2011-03-221-1/+1
| | | | llvm-svn: 128077
* Hook up the MCJIT to the RuntimeDyld library.Jim Grosbach2011-03-221-1/+11
| | | | | | | | 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
* Silence a warning.Jim Grosbach2011-03-181-1/+1
| | | | llvm-svn: 127918
* Beginnings of MC-JIT code generation.Jim Grosbach2011-03-181-5/+27
| | | | | | | | | | | 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
* Merge System into Support.Michael J. Spencer2010-11-291-1/+1
| | | | llvm-svn: 120298
* MCJIT: Stub out MCJIT implementation, still doesn't do anything useful.Daniel Dunbar2010-11-171-0/+92
llvm-svn: 119509
OpenPOWER on IntegriCloud