aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ExecutionEngine
AgeCommit message (Collapse)AuthorFilesLines
2018-04-19[ORC] Fix an assertion condition from r329934.Lang Hames1-2/+2
Thanks to Alexander Ivchenko for finding the issue! llvm-svn: 330359
2018-04-19[ORC] Make VSO symbol resolution/finalization operations private.Lang Hames1-85/+109
This forces these operations to be carried out via a MaterializationResponsibility instance, ensuring responsibility is explicitly tracked. llvm-svn: 330356
2018-04-16[ORC] Add a MaterializationResponsibility class to track responsibility forLang Hames3-58/+125
materializing function definitions. MaterializationUnit instances are responsible for resolving and finalizing symbol definitions when their materialize method is called. By contract, the MaterializationUnit must materialize all definitions it is responsible for and no others. If it can not materialize all definitions (because of some error) then it must notify the associated VSO about each definition that could not be materialized. The MaterializationResponsibility class tracks this responsibility, asserting that all required symbols are resolved and finalized, and that no extraneous symbols are resolved or finalized. In the event of an error it provides a convenience method for notifying the VSO about each definition that could not be materialized. llvm-svn: 330142
2018-04-16[ORC] Merge VSO notifyResolutionFailed and notifyFinalizationFailed in toLang Hames1-35/+16
notifyMaterializationFailed. The notifyMaterializationFailed method can determine which error to raise by looking at which queue the pending queries are in (resolution or finalization). llvm-svn: 330141
2018-04-16Rename ObjectMemoryBuffer to SmallVectorMemoryBuffer; NFCIWeiming Zhao2-2/+2
Summary: As discussed in https://reviews.llvm.org/D45606, it makes more sense to name the class as SmallVectorMemoryBuffer Reviewers: bkramer, dblaikie Reviewed By: dblaikie Subscribers: mehdi_amini, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D45661 llvm-svn: 330107
2018-04-15NFC: Move ObjectMemoryBuffer to supportWeiming Zhao1-1/+1
Summary: Since the class is used by both MCJIT and LTO, it makes more sense to move it to Support lib. This is a follow up patch to r329929 and https://reviews.llvm.org/D45244 Reviewers: bkramer, dblaikie Reviewed By: bkramer Subscribers: mehdi_amini, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D45606 llvm-svn: 330093
2018-04-12[ORC] Use insert rather than emplace.Lang Hames1-19/+19
Hopefully this will fix the build failure at http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/9028 llvm-svn: 329944
2018-04-12[ORC] Plumb error notifications through the VSO interface.Lang Hames4-203/+327
This allows materializers to notify the VSO that they were unable to resolve or finalize symbols. llvm-svn: 329934
2018-04-12[MCJIT] Remove the anchor from mcjit.Benjamin Kramer1-2/+0
This is a layering violation. LTO shouldn't depend on MCJIT. The right fix for this is moving the class somewhere else. llvm-svn: 329929
2018-04-11Add missing vtable anchorsWeiming Zhao4-0/+9
Summary: This patch adds anchor() for MemoryBuffer, raw_fd_ostream, RTDyldMemoryManager, SectionMemoryManager, etc. Reviewers: jlebar, eli.friedman, dblaikie Reviewed By: dblaikie Subscribers: mehdi_amini, mgorny, dblaikie, weimingz, llvm-commits Differential Revision: https://reviews.llvm.org/D45244 llvm-svn: 329861
2018-04-05[RuntimeDyld][PowerPC] Use global entry points for calls between sections.Lang Hames1-9/+13
Functions in different objects may use different TOCs, so calls between such functions should use the global entry point of the callee which updates the TOC pointer. This should fix a bug that the Numba developers encountered (see https://github.com/numba/numba/issues/2451). Patch by Olexa Bilaniuk. Thanks Olexa! No RuntimeDyld checker test case yet as I am not familiar enough with how RuntimeDyldELF fixes up call-sites, but I do not want to hold up landing this. I will continue to work on it and see if I can rope some powerpc experts in. llvm-svn: 329335
2018-04-04Reapply r329133 with fix.Lang Hames1-5/+36
llvm-svn: 329136
2018-04-04Revert r329133 "[RuntimeDyld][AArch64] Add some error pluming / generation..."Lang Hames1-32/+4
This broke a number of buildbots. Looking in to it now... llvm-svn: 329135
2018-04-03[RuntimeDyld][AArch64] Add some error pluming / generation to catch unhandledLang Hames1-4/+32
relocation types on AArch64. llvm-svn: 329133
2018-04-02[ORC] Create a new SymbolStringPool by default in ExecutionSession constructor.Lang Hames3-12/+3
This makes the common case of constructing an ExecutionSession tidier. llvm-svn: 329013
2018-03-28[ORC] Fix ORC on platforms without indirection support.Lang Hames1-1/+5
Previously this crashed because a nullptr (returned by createLocalIndirectStubsManagerBuilder() on platforms without indirection support) functor was unconditionally invoked. Patch by Andres Freund. Thanks Andres! llvm-svn: 328687
2018-03-26Remove unused file, ExecutionEngine/MCJIT/ObjectBuffer.hDavid Blaikie1-48/+0
This header also wasn't self contained/modular - but with no users, it didn't seem worth fixing because it'd break so easily again. llvm-svn: 328565
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
2018-03-20[ORC] Don't fully qualify explicit destructor call -- it confuses some ↵Lang Hames1-4/+2
compilers. This should fix the builder failure at http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/19224 llvm-svn: 327955
2018-03-20[ORC] Rename SymbolSource to MaterializationUnit, and make the materializationLang Hames1-111/+167
operation all-or-nothing, rather than allowing materialization on a per-symbol basis. This addresses a shortcoming of per-symbol materialization: If a MaterializationUnit (/SymbolSource) wants to materialize more symbols than requested (which is likely: most materializers will want to materialize whole modules) then it needs a way to notify the symbol table about the extra symbols being materialized. This process (checking what has been requested against what is being provided and notifying the symbol table about the difference) has to be repeated at every level of the JIT stack. Making materialization all-or-nothing eliminates this issue, simplifying both materializer implementations and the symbol table (VSO class) API. The cost is that per-symbol materialization (e.g. for individual symbols in a module) now requires multiple MaterializationUnits. llvm-svn: 327946
2018-03-15[ORC] Re-apply r327566 with a fix for test-global-ctors.ll.Lang Hames5-47/+69
Also clang-formats the patch, which I should have done the first time around. llvm-svn: 327594
2018-03-14Revert "[ORC] Switch from shared_ptr to unique_ptr for addModule methods."Reid Kleckner4-26/+40
This reverts commit r327566, it breaks test/ExecutionEngine/OrcMCJIT/test-global-ctors.ll. The test doesn't crash with a stack trace, unfortunately. It merely returns 1 as the exit code. ASan didn't produce a report, and I reproduced this on my Linux machine and Windows box. llvm-svn: 327576
2018-03-14[ORC] Switch from shared_ptr to unique_ptr for addModule methods.Lang Hames4-40/+26
Layer implementations typically mutate module state, and this is better reflected by having layers own the Module they are operating on. llvm-svn: 327566
2018-03-14[RuntimeDyld] Silence a compiler error.Lang Hames1-1/+1
This should fix the error at http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/19008 llvm-svn: 327478
2018-03-14[ORC] Fix a data race in the lookup function.Lang Hames1-10/+24
The Error locals need to be protected by a mutex. (This could be fixed by having the promises / futures contain Expected and Error values, but MSVC's future implementation does not support this yet). Hopefully this will fix some of the errors seen on the builders due to r327474. llvm-svn: 327477
2018-03-14[ExecutionEngine] Add a getSymbolTable method to RuntimeDyld.Lang Hames2-0/+21
This can be used to extract the symbol table from a RuntimeDyld instance prior to disposing of it. This patch also updates RTDyldObjectLinkingLayer to use the new method, rather than requesting symbols one at a time via getSymbol. llvm-svn: 327476
2018-03-14[ORC] Silence a compiler error.Lang Hames1-1/+1
This should fix the builder error at http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/19006 llvm-svn: 327475
2018-03-14[ORC] Add a 'lookup' convenience function for finding symbols in a list of VSOs.Lang Hames1-0/+118
The lookup function takes a list of VSOs, a set of symbol names (or just one symbol name) and a materialization function object. It returns an Expected<SymbolMap> (if given a set of names) or an Expected<JITEvaluatedSymbol> (if given just one name). The lookup method constructs an AsynchronousSymbolQuery for the given names, applies that query to each VSO in the list in turn, and then blocks waiting for the query to complete. If threading is enabled then the materialization function object can be used to execute the materialization on different threads. If threading is disabled the MaterializeOnCurrentThread utility must be used. llvm-svn: 327474
2018-03-01[RuntimeDyld][MachO] Fix assertion in encodeAddend, add missing directive toLang Hames1-3/+5
test case. r326290 fixed the assertion for decodeAddend, but not encodeAddend. The regression test failed to catch this because it was missing the subsections_via_symbols flag, so the desired relocation was not applied. This patch also fixes the formatting of the assertion from r326290. llvm-svn: 326406
2018-02-28[TLS] use emulated TLS if the target supports only this modeChih-Hung Hsieh1-0/+2
Emulated TLS is enabled by llc flag -emulated-tls, which is passed by clang driver. When llc is called explicitly or from other drivers like LTO, missing -emulated-tls flag would generate wrong TLS code for targets that supports only this mode. Now use useEmulatedTLS() instead of Options.EmulatedTLS to decide whether emulated TLS code should be generated. Unit tests are modified to run with and without the -emulated-tls flag. Differential Revision: https://reviews.llvm.org/D42999 llvm-svn: 326341
2018-02-28[RuntimeDyld][MachO] Support ARM64_RELOC_BRANCH26 for BL instructions byLang Hames1-2/+4
relaxing an assertion. llvm-svn: 326290
2018-02-21[ORC] Switch to shared_ptr ownership for SymbolSources in VSOs.Lang Hames1-48/+59
This makes it easy to free a SymbolSource (and any related resources) when the last reference in a VSO is dropped. llvm-svn: 325727
2018-02-21[ORC] Switch RTDyldObjectLinkingLayer to take a unique_ptr<MemoryBuffer> ratherLang Hames2-23/+15
than a shared ObjectFile/MemoryBuffer pair. There's no need to pre-parse the buffer into an ObjectFile before passing it down to the linking layer, and moving the parsing into the linking layer allows us remove the parsing code at each call site. llvm-svn: 325725
2018-02-21Handle IMAGE_REL_AMD64_ADDR32NB in RuntimeDyldCOFFFrederich Munch1-21/+94
Summary: IMAGE_REL_AMD64_ADDR32NB relocations are currently set to zero in all cases. This patch sets the relocation to the correct value when possible and shows an error when not. Reviewers: enderby, lhames, compnerd Reviewed By: compnerd Subscribers: LepelTsmok, compnerd, martell, llvm-commits Differential Revision: https://reviews.llvm.org/D30709 llvm-svn: 325700
2018-02-20Report fatal error in the case of out of memorySerge Pavlov1-1/+1
This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
2018-02-15Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov1-1/+1
It caused fails on some buildbots. llvm-svn: 325227
2018-02-15Report fatal error in the case of out of memorySerge Pavlov1-1/+1
Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". There are calls to C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked against null pointer. To simplify checks, new functions are defined in the namespace 'llvm' with the same names as these C function. These functions produce fatal error if allocation fails. User should use 'llvm::malloc' instead of 'std::malloc' in order to use the safe variant. This change replaces 'std::malloc' in the cases when the result of allocation function is not checked against null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statements are added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325224
2018-02-14[ORC] Consolidate RTDyldObjectLinkingLayer GetMemMgr and GetResolver into aLang Hames2-7/+8
unified GetResources callback. Having a single 'GetResources' callback will simplify adding new resources in the future. llvm-svn: 325180
2018-02-14[ORC] Switch to shared_ptr ownership for AsynchronousSymbolQueries.Lang Hames5-35/+39
Queries need to stay alive until each owner has set the values they are responsible for. llvm-svn: 325179
2018-02-09[ORC] Remove Layer handles from the layer concept.Lang Hames2-105/+56
Handles were returned by addModule and used as keys for removeModule, findSymbolIn, and emitAndFinalize. Their job is now subsumed by VModuleKeys, which simplify resource management by providing a consistent handle across all layers. llvm-svn: 324700
2018-02-06[ORC] Use explicit constructor calls to fix a builder error atLang Hames1-3/+3
http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/17627 llvm-svn: 324411
2018-02-06[ORC] Start migrating ORC layers to use the new ORC Core.h APIs.Lang Hames4-86/+251
In particular this patch switches RTDyldObjectLinkingLayer to use orc::SymbolResolver and threads the requried changse (ExecutionSession references and VModuleKeys) through the existing layer APIs. The purpose of the new resolver interface is to improve query performance and better support parallelism, both in JIT'd code and within the compiler itself. The most visibile change is switch of the <Layer>::addModule signatures from: Expected<Handle> addModule(std::shared_ptr<ModuleType> Mod, std::shared_ptr<JITSymbolResolver> Resolver) to: Expected<Handle> addModule(VModuleKey K, std::shared_ptr<ModuleType> Mod); Typical usage of addModule will now look like: auto K = ES.allocateVModuleKey(); Resolvers[K] = createSymbolResolver(...); Layer.addModule(K, std::move(Mod)); See the BuildingAJIT tutorial code for example usage. llvm-svn: 324405
2018-02-03[ORC] Rename NullResolver to NullLegacyResolver.Lang Hames1-2/+3
This resolver conforms to the LegacyJITSymbolResolver interface, and will be replaced with a null-returning resolver conforming to the newer orc::SymbolResolver interface in the near future. This patch renames the class to avoid a clash. llvm-svn: 324175
2018-01-29Move getPlatformFlags to ELFObjectFileBase and simplify.Rafael Espindola1-10/+8
This removes a few std::error_code results that were ignored on every call. llvm-svn: 323674
2018-01-25[ORC] Refactor the various lookupFlags methods to return the flags map via theLang Hames2-5/+6
first argument. This makes lookupFlags more consistent with lookup (which takes the query as the first argument) and composes better in practice, since lookups are usually linearly chained: Each lookupFlags can populate the result map based on the symbols not found in the previous lookup. (If the maps were returned rather than passed by reference there would have to be a merge step at the end). llvm-svn: 323398
2018-01-24Handle R_386_PLT32 in RuntimeDyldELF.Rafael Espindola1-0/+3
This should fix the 32 bit buildbots. llvm-svn: 323344
2018-01-22[ORC] Add orc::SymbolResolver, a Orc/Legacy API interop header, and anLang Hames6-8/+87
orc::SymbolResolver to JITSymbolResolver adapter. The new orc::SymbolResolver interface uses asynchronous queries for better performance. (Asynchronous queries with bulk lookup minimize RPC/IPC overhead, support parallel incoming queries, and expose more available work for distribution). Existing ORC layers will soon be updated to use the orc::SymbolResolver API rather than the legacy llvm::JITSymbolResolver API. Because RuntimeDyld still uses JITSymbolResolver, this patch also includes an adapter that wraps an orc::SymbolResolver with a JITSymbolResolver API. llvm-svn: 323073
2018-01-21[ORC] Add a lookupFlags method to VSO.Lang Hames1-0/+20
lookupFlags returns a SymbolFlagsMap for the requested symbols, along with a set containing the SymbolStringPtr for any symbol not found in the VSO. The JITSymbolFlags for each symbol will have been stripped of its transient JIT-state flags (i.e. NotMaterialized, Materializing). Calling lookupFlags does not trigger symbol materialization. llvm-svn: 323060
2018-01-21[ORC] More cleanup. NFC.Lang Hames1-3/+3
llvm-svn: 323059
2018-01-21[ORC] Cleanup. NFC.Lang Hames1-2/+1
llvm-svn: 323057
generated by cgit v1.1 at 2025-10-17 02:06:56 +0000