summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/MCJIT
Commit message (Collapse)AuthorAgeFilesLines
...
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-291-8/+0
| | | | llvm-svn: 145420
* Sink codegen optimization level into MCCodeGenInfo along side relocation modelEvan Cheng2011-11-161-1/+1
| | | | | | | and code model. This eliminates the need to pass OptLevel flag all over the place and makes it possible for any codegen pass to use this information. llvm-svn: 144788
* Fixed the MCJIT so that it can emit not only instanceSean Callanan2011-11-121-6/+6
| | | | | | | | | | | | | | methods but also class methods for Objective-C. Clang emits Objective-C method names with '\1' at the beginning, and the JIT has pre-existing logic to try prepending a '\1' when searching a module for an instance method (that is, a method whose name begins with '-'). I simply extended it to do the same thing when it encountered a class method (a method whose name begins with '+'). llvm-svn: 144451
* build: Add initial cut at LLVMBuild.txt files.Daniel Dunbar2011-11-031-0/+23
| | | | llvm-svn: 143634
* The MCJITMemoryManager takes ownership of the JMM, so don't leak it.Jim Grosbach2011-10-181-0/+2
| | | | llvm-svn: 142410
* MCJIT initialization TargetDataDanil Malyshev2011-09-301-0/+1
| | | | llvm-svn: 140856
* Fix the asserts in lib/Target/X86/X86ELFWriterInfo.cpp andRichard Trieu2011-09-101-1/+1
| | | | | | | | | | | | lib/ExecutionEngine/MCJIT/MCJIT.cpp from: assert("error"); to: assert(0 && "error"); llvm-svn: 139456
* EE: Provide the symbol "lseek64" explicitly with <unistd.h> on Linux glibc.NAKAMURA Takumi2011-08-141-0/+1
| | | | | | With libcxx, it seems <unistd.h> would not be provided. Thanks to Ryuta Suzuki. llvm-svn: 137567
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified in the same file that the library itself is created. This is more idiomatic for CMake builds, and also allows us to correctly specify dependencies that are missed due to bugs in the GenLibDeps perl script, or change from compiler to compiler. On Linux, this returns CMake to a place where it can relably rebuild several targets of LLVM. I have tried not to change the dependencies from the ones in the current auto-generated file. The only places I've really diverged are in places where I was seeing link failures, and added a dependency. The goal of this patch is not to start changing the dependencies, merely to move them into the correct location, and an explicit form that we can control and change when necessary. This also removes a serialization point in the build because we don't have to scan all the libraries before we begin building various tools. We no longer have a step of the build that regenerates a file inside the source tree. A few other associated cleanups fall out of this. This isn't really finished yet though. After talking to dgregor he urged switching to a single CMake macro to construct libraries with both sources and dependencies in the arguments. Migrating from the two macros to that style will be a follow-up patch. Also, llvm-config is still generated with GenLibDeps.pl, which means it still has slightly buggy dependencies. The internal CMake 'llvm-config-like' macro uses the correct explicitly specified dependencies however. A future patch will switch llvm-config generation (when using CMake) to be based on these deps as well. This may well break Windows. I'm getting a machine set up now to dig into any failures there. If anyone can chime in with problems they see or ideas of how to solve them for Windows, much appreciated. llvm-svn: 136433
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-2/+2
| | | | llvm-svn: 135375
* Avoid a Twine that referenced a tmp (which proceded to go out of scope beforeJim Grosbach2011-05-191-5/+3
| | | | | | the Twine was used). llvm-svn: 131612
* Restore sanity to 131601.Jim Grosbach2011-05-181-2/+3
| | | | llvm-svn: 131603
* Objective C functions may use a magic '\1' on the name. Handle that whenJim Grosbach2011-05-182-1/+16
| | | | | | dealing with them in the MCJIT. llvm-svn: 131601
* ExecutionEngine: push TargetMachine creation into clients (v2)Dylan Noblesmith2011-05-132-18/+2
| | | | | | | | 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-134-100/+2
| | | | | | | This prepares for making JITCtor/MCJITCtor take a TargetMachine* directly from clients like EngineBuilder. llvm-svn: 131316
* The MCJIT memory manager needs to initialize its Module member.Jim Grosbach2011-05-122-2/+2
| | | | llvm-svn: 131234
* Revert ExecutionEngine patches, they either failed to build or broke unit tests.Jakob Stoklund Olesen2011-05-074-2/+116
| | | | | | Please ensure the build is clean and tests are passing when recommitting. llvm-svn: 131044
* ExecutionEngine: delete duplicated filesDylan Noblesmith2011-05-061-91/+0
| | | | | | Forgot to `svn rm` these in revisions 131025 / 131029. llvm-svn: 131030
* ExecutionEngine: push TargetMachine creation into clientsDylan Noblesmith2011-05-062-18/+2
| | | | | | | | 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-063-9/+2
| | | | | | | This prepares for making JITCtor/MCJITCtor take a TargetMachine* directly from clients like EngineBuilder. llvm-svn: 131025
* 80-col fix.Eric Christopher2011-04-221-1/+1
| | | | llvm-svn: 129973
* MCJIT relocation resolution.Jim Grosbach2011-04-131-0/+2
| | | | llvm-svn: 129445
* Refactor MCJIT 32-bit section loading.Jim Grosbach2011-04-081-0/+6
| | | | | | | 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
* RuntimeDyld should use the memory manager API.Jim Grosbach2011-04-061-9/+5
| | | | | | | | | | 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
* Remove extraneous 'return'.Jim Grosbach2011-04-051-2/+1
| | | | llvm-svn: 128959
* Add missing file from r128851.Jim Grosbach2011-04-041-0/+58
| | | | llvm-svn: 128856
* Layer the memory manager between the JIT and the runtime Dyld.Jim Grosbach2011-04-042-5/+9
| | | | | | | | | | | 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 missing file from previous commit.Jim Grosbach2011-03-221-0/+161
| | | | llvm-svn: 128095
* Add simple arg passing to MC-JIT and support for exit() call.Jim Grosbach2011-03-223-4/+115
| | | | | | | | | | | | | 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-222-1/+14
| | | | | | | | 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-182-6/+47
| | | | | | | | | | | 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-292-2/+2
| | | | llvm-svn: 120298
* MCJIT: Stub out MCJIT implementation, still doesn't do anything useful.Daniel Dunbar2010-11-175-0/+268
llvm-svn: 119509
OpenPOWER on IntegriCloud