aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ExecutionEngine/ExecutionEngineBindings.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-07-30Remove trailing spaceFangrui Song1-8/+8
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
2018-07-25Move JIT listener C binding fallbackks to ExecutionEngineBindings.cpp.Andres Freund1-0/+24
Initially, in https://reviews.llvm.org/D44890, I had these defined as empty functions inside the header when the respective event listener was not built in. As done in that commit, that wasn't correct, because it was a ODR violation. Krasimir hot-fixed that in r333265, but that wasn't quite right either, because it'd lead to the symbol not being available. Instead just move the fallbacksto ExecutionEngineBindings.cpp. Could define them as static inlines in the header too, but I don't think it matters. Reviewers: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49654 llvm-svn: 337930
2018-03-23Fix layering by moving Support/CodeGenCWrappers.h to TargetDavid Blaikie1-1/+1
This includes llvm-c/TargetMachine.h which is logically part of libTarget (since libTarget implements llvm-c/TargetMachine.h's functions). llvm-svn: 328394
2017-08-03Delete Default and JITDefault code modelsRafael Espindola1-1/+3
IMHO it is an antipattern to have a enum value that is Default. At any given piece of code it is not clear if we have to handle Default or if has already been mapped to a concrete value. In this case in particular, only the target can do the mapping and it is nice to make sure it is always done. This deletes the two default enum values of CodeModel and uses an explicit Optional<CodeModel> when it is possible that it is unspecified. llvm-svn: 309911
2017-03-21Rename AttributeSet to AttributeListReid Kleckner1-1/+1
Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2016-10-01Use StringRef instead of raw pointer in ExecutionEngineMehdi Amini1-1/+1
llvm-svn: 283016
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
generated by cgit v1.1 at 2025-10-09 07:10:18 +0000