aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ExecutionEngine/ExecutionEngine.cpp
AgeCommit message (Collapse)AuthorFilesLines
2014-12-03[MCJIT] Unique-ptrify the RTDyldMemoryManager member of MCJIT. NFC.Lang Hames1-2/+16
llvm-svn: 223183
2014-11-27[MCJIT] Replace JITEventListener::anchor (temporarily removed in r222861), andLang Hames1-0/+2
move GDBRegistrationListener into ExecutionEngine to avoid layering violation. llvm-svn: 222864
2014-11-27[MCJIT] Remove JITEventListener's anchor until I can determine the right placeLang Hames1-3/+0
to put it. This should unbreak the Mips bots. llvm-svn: 222861
2014-11-26[MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.Lang Hames1-7/+4
llvm-svn: 222840
2014-11-26Reverting r222828 and r222810-r222812 as they broke the build on Windows.Aaron Ballman1-4/+7
http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/11753 llvm-svn: 222833
2014-11-26[MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.Lang Hames1-7/+4
Previously, when loading an object file, RuntimeDyld (1) took ownership of the ObjectFile instance (and associated MemoryBuffer), (2) potentially modified the object in-place, and (3) returned an ObjectImage that managed ownership of the now-modified object and provided some convenience methods. This scheme accreted over several years as features were tacked on to RuntimeDyld, and was both unintuitive and unsafe (See e.g. http://llvm.org/PR20722). This patch fixes the issue by removing all ownership and in-place modification of object files from RuntimeDyld. Existing behavior, including debugger registration, is preserved. Noteworthy changes include: (1) ObjectFile instances are now passed to RuntimeDyld by const-ref. (2) The ObjectImage and ObjectBuffer classes have been removed entirely, they existed to model ownership within RuntimeDyld, and so are no longer needed. (3) RuntimeDyld::loadObject now returns an instance of a new class, RuntimeDyld::LoadedObjectInfo, which can be used to construct a modified object suitable for registration with the debugger, following the existing debugger registration scheme. (4) The JITRegistrar class has been removed, and the GDBRegistrar class has been re-written as a JITEventListener. This should fix http://llvm.org/PR20722 . llvm-svn: 222810
2014-10-20IR: Replace DataLayout::RoundUpAlignment with RoundUpToAlignmentDavid Majnemer1-2/+2
No functional change intended, just cleaning up some code. llvm-svn: 220187
2014-09-23[MCJIT] Remove a few more references to JITMemoryManager that survived r218316.Lang Hames1-1/+0
llvm-svn: 218318
2014-09-23[MCJIT] Delete the JTIMemoryManager and associated APIs.Lang Hames1-6/+4
This patch removes the old JIT memory manager (which does not provide any useful functionality now that the old JIT is gone), and migrates the few remaining clients over to SectionMemoryManager. http://llvm.org/PR20848 llvm-svn: 218316
2014-09-02unique_ptrify passing the TargetMachine to ExecutionEngine::MCJITCtorDavid Blaikie1-5/+3
llvm-svn: 216988
2014-09-02Reinstate "Nuke the old JIT."Eric Christopher1-26/+2
Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
2014-08-26Give ExecutionEngine of top level buffers.Rafael Espindola1-0/+5
Long term the idea if for the engine to not own the buffers, but for now this is consistent with the rest of the API. llvm-svn: 216484
2014-08-26ExecutionEngine: address review commentsDylan Noblesmith1-7/+6
llvm-svn: 216427
2014-08-25ExecutionEngine: unique_ptr-ifyDylan Noblesmith1-20/+12
NFC. llvm-svn: 216362
2014-08-19Don't own the buffer in object::Binary.Rafael Espindola1-1/+1
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-19Make it explicit that ExecutionEngine takes ownership of the modules.Rafael Espindola1-18/+16
llvm-svn: 215967
2014-08-18Use a range loop. NFC.Rafael Espindola1-2/+2
llvm-svn: 215948
2014-08-07Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher1-2/+25
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-25/+2
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-08-01Include Archive.hRafael Espindola1-0/+1
MSVC was complaining about Archive being an incomplete type. llvm-svn: 214542
2014-08-01Move virtual method out of line.Rafael Espindola1-0/+4
Should fix the MSVC build. llvm-svn: 214539
2014-07-31Delete dead code.Rafael Espindola1-2/+1
llvm-svn: 214370
2014-07-24Remove dead code.Rafael Espindola1-51/+0
Every user has been switched to using EngineBuilder. llvm-svn: 213871
2014-07-01ExecutionEngine::create(): fix interpreter fallback when JIT is unavailableAlp Toker1-7/+8
ForceInterpreter=false shouldn't disable the interpreter completely because it can still be necessary to interpret if the target doesn't support JIT. No obvious way to test this in LLVM, but this matches what LLVMCreateExecutionEngineForModule() does and fixes the clang-interpreter example in the clang source tree which uses the ExecutionEngine. llvm-svn: 212086
2014-06-20Revert "Replace Execution Engine's mutex with std::recursive_mutex."Zachary Turner1-8/+8
This reverts commit 1f502bd9d7d2c1f98ad93a09ffe435e11a95aedd, due to GCC / MinGW's lack of support for C++11 threading. It's possible this will go back in after we come up with a reasonable solution. llvm-svn: 211401
2014-06-18Replace Execution Engine's mutex with std::recursive_mutex.Zachary Turner1-8/+8
This change has a bit of a trickle down effect due to the fact that there are a number of derived implementations of ExecutionEngine, and that the mutex is not tightly encapsulated so is used by other classes directly. Reviewed by: rnk Differential Revision: http://reviews.llvm.org/D4196 llvm-svn: 211214
2014-06-16Clean up some unnecessary mutex guards.Zachary Turner1-25/+24
These were being used as unreferenced parameters to enforce that the methods must not be called without holding a mutex, but all of the methods in question were internal, and the methods were only exposed through an interface whose entire purpose was to serialize access to these structures, so expecting the methods to be accessed under a mutex is reasonable enough. Reviewed by: blaikie Differential Revision: http://reviews.llvm.org/D4162 llvm-svn: 211054
2014-05-31ExecutionEngine: avoid NDEBUG in headersAlp Toker1-0/+21
llvm-svn: 209981
2014-05-08Use range loop.Rafael Espindola1-25/+21
llvm-svn: 208346
2014-04-29Fix MSVC build broken by r207580David Blaikie1-0/+5
Seems MSVC wants to be able to codegen inline-definitions of virtual functions even in TUs that don't define the key function - and it's well within its rights to do so. llvm-svn: 207581
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-18[ExecutionEngine] Allow JIT clients to enable/disable module verification.Lang Hames1-10/+20
Previously module verification was always enabled, with no way to turn it off. As of this commit, module verification is on by default in Debug builds, and off by default in release builds. The default behaviour can be overridden by calling setVerifyModules(bool) on the JIT instance (this works for both the old JIT, and MCJIT). <rdar://problem/16150008> llvm-svn: 206561
2014-04-15[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-31/+31
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-1/+1
class. llvm-svn: 203344
2014-03-06Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles1-1/+1
This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
2014-03-05[C++11] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles1-2/+2
llvm-svn: 202957
2014-03-04[Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth1-1/+1
Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. llvm-svn: 202821
2014-02-18Rename some member variables from TD to DL.Rafael Espindola1-5/+5
TargetData was renamed DataLayout back in r165242. llvm-svn: 201581
2014-01-14Decouple dllexport/dllimport from linkageNico Rieck1-3/+1
Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199218
2014-01-14Revert "Decouple dllexport/dllimport from linkage"Nico Rieck1-1/+3
Revert this for now until I fix an issue in Clang with it. This reverts commit r199204. llvm-svn: 199207
2014-01-14Decouple dllexport/dllimport from linkageNico Rieck1-3/+1
Representing dllexport/dllimport as distinct linkage types prevents using these attributes on templates and inline functions. Instead of introducing further mixed linkage types to include linkonce and weak ODR, the old import/export linkage types are replaced with a new separate visibility-like specifier: define available_externally dllimport void @f() {} @Var = dllexport global i32 1, align 4 Linkage for dllexported globals and functions is now equal to their linkage without dllexport. Imported globals and functions must be either declarations with external linkage, or definitions with AvailableExternallyLinkage. llvm-svn: 199204
2014-01-07Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth1-2/+2
subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
2013-11-19[weak vtables] Remove a bunch of weak vtablesJuergen Ributzka1-0/+6
This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. The memory leaks in this version have been fixed. Thanks Alexey for pointing them out. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 195064
2013-11-18Revert r194865 and r194874.Alexey Samsonov1-4/+0
This change is incorrect. If you delete virtual destructor of both a base class and a subclass, then the following code: Base *foo = new Child(); delete foo; will not cause the destructor for members of Child class. As a result, I observe plently of memory leaks. Notable examples I investigated are: ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl. llvm-svn: 194997
2013-11-15[weak vtables] Remove a bunch of weak vtablesJuergen Ributzka1-0/+4
This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 194865
2013-11-15Don't try to initialize memory for a global if the allocation failed in ↵Andrew Kaylor1-0/+4
ExecutionEngine. Patch by Dale Martin! llvm-svn: 194831
2013-10-07Remove dead code.Rafael Espindola1-13/+1
Support for exception handling in the legacy JIT was removed in r181354 and this code was dead since then. Thanks to Yaron Keren for noticing it. llvm-svn: 192101
2013-09-12LLVM Interpreter: implementation of "insertvalue" and "extractvalue";Elena Demikhovsky1-1/+19
undef constatnt for structure and test for these functions. done by Yuri Veselov (mailto:Yuri.Veselov@intel.com) llvm-svn: 190599
2013-07-04Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid ↵Craig Topper1-1/+1
specifying the vector size. llvm-svn: 185606
2013-05-14SectionMemoryManager shouldn't be a JITMemoryManager. Previously, the Filip Pizlo1-3/+14
EngineBuilder interface required a JITMemoryManager even if it was being used to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager. Consequently, the SectionMemoryManager, which is meant for MCJIT, derived from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager methods that weren't relevant to the MCJIT. This patch fixes the situation: it teaches the EngineBuilder that RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if we're using the MCJIT. This allows us to remove the stub methods from SectionMemoryManager, and make SectionMemoryManager a direct subtype of RTDyldMemoryManager. llvm-svn: 181820
generated by cgit v1.1 at 2025-10-18 05:59:56 +0000