summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/ExecutionEngine/Orc/ObjectLinkingLayerTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Orc] Rename ObjectLinkingLayer -> RTDyldObjectLinkingLayer.Lang Hames2017-02-201-247/+0
| | | | | | | | | | The current ObjectLinkingLayer (now RTDyldObjectLinkingLayer) links objects in-process using MCJIT's RuntimeDyld class. In the near future I hope to add new object linking layers (e.g. a remote linking layer that links objects in the JIT target process, rather than the client), so I'm renaming this class to be more descriptive. llvm-svn: 295636
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-011-5/+5
| | | | | | | | | | | | | | | | This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class that is capable of lazy materialization (i.e. the symbol definition needn't be emitted until the address is requested). This can be used to support common and weak symbols in the JIT (though this is not implemented in this patch). For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver. For space efficiency a new class, JITEvaluatedSymbol, is introduced that behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an address and symbol flags. Instances of JITEvaluatedSymbol can be used in symbol-tables to avoid paying the space cost of the materializer. llvm-svn: 277386
* [Orc] Add conversion to/from RuntimeDyld::SymbolInfo for JITSymbol.Lang Hames2016-05-311-1/+1
| | | | | | | | | | This tidies up some code that was manually constructing RuntimeDyld::SymbolInfo instances from JITSymbols. It will save more mess in the future when JITSymbol::getAddress is extended to return an Expected<TargetAddress> rather than just a TargetAddress, since we'll be able to embed the error checking in the conversion. llvm-svn: 271350
* Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini2016-04-141-17/+15
| | | | | | | | | | | At the same time, fixes InstructionsTest::CastInst unittest: yes you can leave the IR in an invalid state and exit when you don't destroy the context (like the global one), no longer now. This is the first part of http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266379
* Fix Clang-tidy modernize-use-nullptr and modernize-use-override warnings; ↵Eugene Zelenko2016-01-261-6/+2
| | | | | | | | other minor fixes. Differential revision: reviews.llvm.org/D16568 llvm-svn: 258831
* [Orc] Refactor ObjectLinkingLayer::addObjectSet to defer loading objects untilLang Hames2016-01-191-0/+72
| | | | | | | | | | | | | | | | they're needed. Prior to this patch objects were loaded (via RuntimeDyld::loadObject) when they were added to the ObjectLinkingLayer, but were not relocated and finalized until a symbol address was requested. In the interim, another object could be loaded and finalized with the same memory manager, causing relocation/finalization of the first object to fail (as the first finalization call may have marked the allocated memory for the first object read-only). By deferring the loadObject call (and subsequent memory allocations) until an object file is needed we can avoid prematurely finalizing memory. llvm-svn: 258185
* [Orc] Expand a comment explaining a unit test.Lang Hames2016-01-181-0/+5
| | | | llvm-svn: 258032
* OrcJITTests//ObjectLinkingLayerTest.cpp: Appease msc18's C2327. It seems ↵NAKAMURA Takumi2016-01-101-9/+9
| | | | | | | | | | | definition of nested class would confuse the context. llvm\unittests\ExecutionEngine\Orc\ObjectLinkingLayerTest.cpp(115) : error C2327: 'llvm::OrcExecutionTest::TM' : is not a type name, static, or enumerator llvm\unittests\ExecutionEngine\Orc\ObjectLinkingLayerTest.cpp(115) : error C2065: 'TM' : undeclared identifier FYI, "this->TM" was valid even before moving class SectionMemoryManagerWrapper. llvm-svn: 257290
* [Orc][RuntimeDyld] Prevent duplicate calls to finalizeMemory on shared memoryLang Hames2016-01-091-0/+82
| | | | | | | | | | | | | | | | | | | | | | | managers. Prior to this patch, recursive finalization (where finalization of one RuntimeDyld instance triggers finalization of another instance on which the first depends) could trigger memory access failures: When the inner (dependent) RuntimeDyld instance and its memory manager are finalized, memory allocated (but not yet relocated) by the outer instance is locked, and relocation in the outer instance fails with a memory access error. This patch adds a latch to the RuntimeDyld::MemoryManager base class that is checked by a new method: RuntimeDyld::finalizeWithMemoryManagerLocking, ensuring that shared memory managers are only finalized by the outermost RuntimeDyld instance. This allows ORC clients to supply the same memory manager to multiple calls to addModuleSet. In particular it enables the use of user-supplied memory managers with the CompileOnDemandLayer which must reuse the supplied memory manager for each function that is lazily compiled. llvm-svn: 257263
* [Orc] Add missing file for r251604.Lang Hames2015-10-291-0/+94
llvm-svn: 251605
OpenPOWER on IntegriCloud