aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ExecutionEngine/ExecutionEngineBindings.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-02-13Support: Fix incremental build when re-configuring targetsDuncan P. N. Exon Smith1-0/+1
r180893 added an indirect include of llvm/Config/Targets.def to llvm/Support/CodeGen.h, which in turn is included by things like llvm/IR/Module.h. After a full build of LLVM and Clang, ninja had to rebuild 1274 files after reconfiguring. This commit strips CodeGen.h back down to just a pile of enums and moves the expensive includes over to CodeGenCWrappers.h (which is only included in two places). This gets ninja down to 88 files if you reconfigure with, e.g., -DLLVM_TARGETS_TO_BUILD=X86. llvm-svn: 260835
2016-01-15LLVMRunStaticConstructors can be called before object is finalized, #24028Amaury Sechet1-0/+2
Summary: Since you cannot call finalizeObject manually through the C-API and other functions from the C-API automatically call it, LLVMRunStaticConstructors should also call it or otherwise you cannot call it without first calling a workaround function (or call any other function from the C-API which implicitly finalizes the object). Reviewers: dnovillo, spatel, bkramer, deadalnix, joker.eph, echristo, lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16188 llvm-svn: 257849
2015-12-19Delete APIs that have been deprecated since 2010.Rafael Espindola1-42/+0
llvm-svn: 256107
2015-07-27Fix ODR violation. NFC.Diego Novillo1-1/+1
There is an ODR conflict between lib/ExecutionEngine/ExecutionEngineBindings.cpp and lib/Target/TargetMachineC.cpp. The inline definitions should simply be marked static (thanks dblaikie for the hint). llvm-svn: 243298
2015-07-16Make ExecutionEngine owning a DataLayoutMehdi Amini1-1/+1
Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. The ExecutionEngine will act as an exception and will be unsafe to be reused across context. We don't enforce this rule but undefined behavior can occurs if the user tries to do it. Reviewers: lhames Subscribers: echristo, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11110 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 242414
2015-07-16Revert "Make ExecutionEngine owning a DataLayout"Michael Kuperstein1-1/+1
Reverting to fix buildbot breakage. This reverts commit r242387. llvm-svn: 242394
2015-07-16Make ExecutionEngine owning a DataLayoutMehdi Amini1-1/+1
Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. The ExecutionEngine will act as an exception and will be unsafe to be reused across context. We don't enforce this rule but undefined behavior can occurs if the user tries to do it. Reviewers: lhames Subscribers: echristo, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11110 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 242387
2015-06-01add missing dependency for ExecutionEngine libSanjay Patel1-0/+1
This appears to be masked most of the time, but the problem was exposed on some bots by r238051. llvm-svn: 238788
2015-05-29Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer1-5/+2
If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
2015-05-26Remove NoFramePointerElim and NoFramePointerElimOverride from TargetOptions andAkira Hatanaka1-3/+7
remove ExecutionEngine's dependence on CodeGen. NFC. This is a follow-up to r238080. Differential Revision: http://reviews.llvm.org/D9830 llvm-svn: 238244
2015-05-23Stop resetting NoFramePointerElim in TargetMachine::resetTargetOptions.Akira Hatanaka1-1/+8
This is part of the work to remove TargetMachine::resetTargetOptions. In this patch, instead of updating global variable NoFramePointerElim in resetTargetOptions, its use in DisableFramePointerElim is replaced with a call to TargetFrameLowering::noFramePointerElim. This function determines on a per-function basis if frame pointer elimination should be disabled. There is no change in functionality except that cl:opt option "disable-fp-elim" can now override function attribute "no-frame-pointer-elim". llvm-svn: 238080
2015-04-11Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko1-1/+1
The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
2014-12-22[C API] Expose LLVMGetGlobalValueAddress and LLVMGetFunctionAddress.Peter Zotov1-0/+8
Patch by Ramkumar Ramachandra <artagnon@gmail.com> llvm-svn: 224720
2014-12-03[MCJIT] Unique-ptrify the RTDyldMemoryManager member of MCJIT. NFC.Lang Hames1-1/+2
llvm-svn: 223183
2014-09-02Reinstate "Nuke the old JIT."Eric Christopher1-3/+1
Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
2014-08-21Remove dead code. NFC.Rafael Espindola1-8/+0
llvm-svn: 216201
2014-08-19Make it explicit that ExecutionEngine takes ownership of the modules.Rafael Espindola1-5/+5
llvm-svn: 215967
2014-08-07Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher1-1/+3
be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
2014-08-07Nuke the old JIT.Rafael Espindola1-3/+1
I am sure we will be finding bits and pieces of dead code for years to come, but this is a good start. Thanks to Lang Hames for making MCJIT a good replacement! llvm-svn: 215111
2014-05-13[un]wrap extracted from lib/Target/Target[MachineC].cpp, ↵Artyom Skrobov1-8/+0
lib/ExecutionEngine/ExecutionEngineBindings.cpp into include/llvm/IR/DataLayout.h llvm-svn: 208680
2014-04-22[Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth1-1/+2
definition below all the header #include lines. This updates most of the miscellaneous other lib/... directories. A few left though. llvm-svn: 206845
2014-04-15[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-2/+2
instead of comparing to nullptr. llvm-svn: 206252
2014-03-08[C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper1-9/+9
class. llvm-svn: 203344
2014-01-23Add target analysis passes to the codegen pipeline for MCJIT.Juergen Ributzka1-0/+10
This patch adds the target analysis passes (usually TargetTransformInfo) to the codgen pipeline. We also expose now the AddAnalysisPasses method through the C API, because the optimizer passes would also benefit from better target-specific cost models. Reviewed by Andrew Kaylor llvm-svn: 199926
2013-10-02This threads SectionName through the allocateCodeSection/allocateDataSection ↵Filip Pizlo1-8/+13
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
2013-09-30llvm-c: use typedef for function pointersAnders Waldenborg1-16/+8
This makes it consistent with other function pointers used in llvm-c Differential Revision: http://llvm-reviews.chandlerc.com/D1712 llvm-svn: 191693
2013-09-20Revert "llvm-c: Add LLVMGetPointerToFunction"Anders Waldenborg1-4/+0
This reverts r191030 llvm-svn: 191075
2013-09-19llvm-c: Add LLVMGetPointerToFunctionAnders Waldenborg1-0/+4
Differential Revision: http://llvm-reviews.chandlerc.com/D1715 llvm-svn: 191030
2013-05-22Expose the RTDyldMemoryManager through the C API. This allows clients of Filip Pizlo1-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
2013-05-21Roll out r182407 and r182408 because they broke builds.Filip Pizlo1-111/+3
llvm-svn: 182409
2013-05-21Expose the RTDyldMemoryManager through the C API. This allows clients of Filip Pizlo1-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
2013-05-01This exposes more MCJIT options via the C API:Filip Pizlo1-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
2013-05-01This patch breaks up Wrap.h so that it does not have to include all of Filip Pizlo1-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
2013-04-29Exposing MCJIT through C APIAndrew Kaylor1-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
2013-04-25Revert "Exposing MCJIT through C API"Rafael Espindola1-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
2013-04-24Exposing MCJIT through C APIAndrew Kaylor1-0/+48
Patch by Filip Pizlo llvm-svn: 180229
2013-04-23Fix dependency layering issues caused by r180112.Eric Christopher1-1/+0
Patch by Tom Stellard. (Committed while he's afk per request) llvm-svn: 180157
2013-04-23Wrap.h: Define wrap / unwrap function for ExecutionEngineTom Stellard1-1/+0
llvm-svn: 180112
2013-04-22Move C++ code out of the C headers and into either C++ headersEric Christopher1-0/+22
or the C++ files themselves. This enables people to use just a C compiler to interoperate with LLVM. llvm-svn: 180063
2012-12-03Use the new script to sort the includes of every file under lib.Chandler Carruth1-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
2012-10-08Move TargetData to DataLayout.Micah Villmow1-1/+1
llvm-svn: 165402
2012-01-20More dead code removal (using -Wunreachable-code)David Blaikie1-2/+0
llvm-svn: 148578
2010-07-19Fix indentation.Duncan Sands1-1/+1
llvm-svn: 108691
2010-07-19Expose JIT::recompileAndRelinkFunction for use through the C API.Duncan Sands1-0/+4
Patch by Benjamin Saunders. llvm-svn: 108690
2010-03-02Add Module functions in place of module providers.Erick Tryzelaar1-18/+59
llvm-svn: 97608
2010-01-27Kill ModuleProvider and ghost linkage by inverting the relationship betweenJeffrey Yasskin1-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
2010-01-09"In order to ease automatic bindings generation, it would be helpful if ↵Chris Lattner1-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
2009-07-18Add EngineBuilder to ExecutionEngine in favor of the five optional argument ↵Reid Kleckner1-6/+13
EE::create(). Also a test commit. llvm-svn: 76276
2009-07-14llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable.Torok Edwin1-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
2009-07-11assert(0) -> LLVM_UNREACHABLE.Torok Edwin1-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
generated by cgit v1.1 at 2025-10-15 19:26:15 +0000