summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/ExecutionEngineBindings.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Expose the RTDyldMemoryManager through the C API. This allows clients of Filip Pizlo2013-05-221-3/+111
| | | | | | | | the C API to provide their own way of allocating JIT memory (both code and data) and finalizing memory permissions (page protections, cache flush). llvm-svn: 182448
* Roll out r182407 and r182408 because they broke builds.Filip Pizlo2013-05-211-111/+3
| | | | llvm-svn: 182409
* Expose the RTDyldMemoryManager through the C API. This allows clients of Filip Pizlo2013-05-211-3/+111
| | | | | | | | the C API to provide their own way of allocating JIT memory (both code and data) and finalizing memory permissions (page protections, cache flush). llvm-svn: 182408
* This exposes more MCJIT options via the C API:Filip Pizlo2013-05-011-9/+23
| | | | | | | | | | | | | | | | | | | | | 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
* This patch breaks up Wrap.h so that it does not have to include all of Filip Pizlo2013-05-011-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | the things, and renames it to CBindingWrapping.h. I also moved CBindingWrapping.h into Support/. This new file just contains the macros for defining different wrap/unwrap methods. The calls to those macros, as well as any custom wrap/unwrap definitions (like for array of Values for example), are put into corresponding C++ headers. Doing this required some #include surgery, since some .cpp files relied on the fact that including Wrap.h implicitly caused the inclusion of a bunch of other things. This also now means that the C++ headers will include their corresponding C API headers; for example Value.h must include llvm-c/Core.h. I think this is harmless, since the C API headers contain just external function declarations and some C types, so I don't believe there should be any nasty dependency issues here. llvm-svn: 180881
* Exposing MCJIT through C APIAndrew Kaylor2013-04-291-0/+46
| | | | | | | | Re-submitting with fix for OCaml dependency problems (removing dependency on SectionMemoryManager when it isn't used). Patch by Fili Pizlo llvm-svn: 180720
* Revert "Exposing MCJIT through C API"Rafael Espindola2013-04-251-48/+0
| | | | | | | | | | 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
* Exposing MCJIT through C APIAndrew Kaylor2013-04-241-0/+48
| | | | | | Patch by Filip Pizlo llvm-svn: 180229
* Fix dependency layering issues caused by r180112.Eric Christopher2013-04-231-1/+0
| | | | | | Patch by Tom Stellard. (Committed while he's afk per request) llvm-svn: 180157
* Wrap.h: Define wrap / unwrap function for ExecutionEngineTom Stellard2013-04-231-1/+0
| | | | llvm-svn: 180112
* Move C++ code out of the C headers and into either C++ headersEric Christopher2013-04-221-0/+22
| | | | | | | or the C++ files themselves. This enables people to use just a C compiler to interoperate with LLVM. llvm-svn: 180063
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Move TargetData to DataLayout.Micah Villmow2012-10-081-1/+1
| | | | llvm-svn: 165402
* More dead code removal (using -Wunreachable-code)David Blaikie2012-01-201-2/+0
| | | | llvm-svn: 148578
* Fix indentation.Duncan Sands2010-07-191-1/+1
| | | | llvm-svn: 108691
* Expose JIT::recompileAndRelinkFunction for use through the C API.Duncan Sands2010-07-191-0/+4
| | | | | | Patch by Benjamin Saunders. llvm-svn: 108690
* Add Module functions in place of module providers.Erick Tryzelaar2010-03-021-18/+59
| | | | llvm-svn: 97608
* Kill ModuleProvider and ghost linkage by inverting the relationship betweenJeffrey Yasskin2010-01-271-9/+5
| | | | | | | | | | | | | | | | | | | | | Modules and ModuleProviders. Because the "ModuleProvider" simply materializes GlobalValues now, and doesn't provide modules, it's renamed to "GVMaterializer". Code that used to need a ModuleProvider to materialize Functions can now materialize the Functions directly. Functions no longer use a magic linkage to record that they're materializable; they simply ask the GVMaterializer. Because the C ABI must never change, we can't remove LLVMModuleProviderRef or the functions that refer to it. Instead, because Module now exposes the same functionality ModuleProvider used to, we store a Module* in any LLVMModuleProviderRef and translate in the wrapper methods. The bindings to other languages still use the ModuleProvider concept. It would probably be worth some time to update them to follow the C++ more closely, but I don't intend to do it. Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735. llvm-svn: 94686
* "In order to ease automatic bindings generation, it would be helpful if ↵Chris Lattner2010-01-091-17/+17
| | | | | | | | boolean values were distinguishable from integers. The attached patch introduces "typedef int LLVMBool;", and uses LLVMBool instead of int throughout the C API, wherever a boolean value is called for." Patch by James Y Knight! llvm-svn: 93079
* Add EngineBuilder to ExecutionEngine in favor of the five optional argument ↵Reid Kleckner2009-07-181-6/+13
| | | | | | | | EE::create(). Also a test commit. llvm-svn: 76276
* llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable.Torok Edwin2009-07-141-2/+2
| | | | | | | | | This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
* assert(0) -> LLVM_UNREACHABLE.Torok Edwin2009-07-111-3/+3
| | | | | | | | | Make llvm_unreachable take an optional string, thus moving the cerr<< out of line. LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for NDEBUG builds. llvm-svn: 75379
* Fix the EE bindings to use the proper EE interfaces for creating a JIT.Chris Lattner2009-06-161-1/+1
| | | | | | Calling into createJIT directly creates a circular dependency between libjit and lib ee. llvm-svn: 73567
* Fix the JIT bindings for ocaml.Bill Wendling2009-04-301-3/+4
| | | | llvm-svn: 70454
* Instead of passing in an unsigned value for the optimization level, use an enum,Bill Wendling2009-04-291-1/+1
| | | | | | | which better identifies what the optimization is doing. And is more flexible for future uses. llvm-svn: 70440
* The second part of the change from -fast to -O#. This changes the JIT to acceptBill Wendling2009-04-291-2/+2
| | | | | | | an optimization level instead of a simple boolean telling it to generate code "fast" or the other type of "fast". llvm-svn: 70347
* add getPointerToGlobal to the C bindings, patch by Lennart Augustsson!Chris Lattner2009-01-211-0/+4
| | | | | | PR3364 llvm-svn: 62697
* Fix the LLVMCreateJITCompiler C binding.Gordon Henriksen2008-08-081-3/+3
| | | | | | | Evan broke it in r54523 by adding a parameter in the implementation without updating the header correspondingly. llvm-svn: 54555
* Add new parameter Fast to createJIT to enable the fast codegen path.Evan Cheng2008-08-081-2/+4
| | | | llvm-svn: 54523
* Add C binding for ExecutionEngine::addGlobalMapping.Gordon Henriksen2008-06-201-0/+5
| | | | llvm-svn: 52523
* PR2202: LLVMCreateInterpreter creates a JITGordon Henriksen2008-04-251-1/+1
| | | | | | Applying fix by Frits van Bommel. llvm-svn: 50249
* Fix "Control reaches the end of non-void function" warnings, Chris Lattner2008-03-301-0/+1
| | | | | | patch by David Chisnall. llvm-svn: 48963
* Expose ExecutionEngine::getTargetData() to c and ocaml bindings.Erick Tryzelaar2008-03-271-0/+4
| | | | llvm-svn: 48851
* Unbreak build with gcc 4.3: provide missed includes and silence most ↵Anton Korobeynikov2008-02-201-0/+1
| | | | | | annoying warnings. llvm-svn: 47367
* I doubt the address of the Error string was intendedDuncan Sands2008-01-071-1/+2
| | | | | | | to be used for the force_interpreter parameter... Spotted by gcc-4.2. llvm-svn: 45714
* Remove attribution from file headers, per discussion on llvmdev.Chris Lattner2007-12-291-2/+2
| | | | llvm-svn: 45418
* C and Ocaml bindings for ExecutionEngine (i.e., the JIT compiler).Gordon Henriksen2007-12-231-0/+187
llvm-svn: 45335
OpenPOWER on IntegriCloud