summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
* Fix a build failure with perf: Add a missing include to ↵Sylvestre Ledru2019-11-161-0/+1
| | | | | | | | llvm/Support/ManagedStatic.h It was failing with PerfJITEventListener.cpp:489:7: error: 'ManagedStatic' in namespace 'llvm' does not name a template type llvm::ManagedStatic<PerfJITEventListener> PerfListener;
* Fix GCC -Wcast-qual warningsHans Wennborg2019-11-151-2/+2
|
* GCC 5.3 build fixHans Wennborg2019-11-151-1/+1
| | | | | | | | | | It was failing with llvm/lib/ExecutionEngine/Orc/DebugUtils.cpp:56:10: error: could not convert ‘Obj’ from ‘std::unique_ptr<llvm::MemoryBuffer>’ to ‘llvm::Expected<std::unique_ptr<llvm::MemoryBuffer> >’ return Obj; ^
* [ORC] Add a utility to support dumping JIT'd objects to disk for debugging.Lang Hames2019-11-145-12/+86
| | | | | | | | | Adds a DumpObjects utility that can be used to dump JIT'd objects to disk. Instances of DebugObjects may be used by ObjectTransformLayer as no-op transforms. This patch also adds an ObjectTransformLayer to LLJIT and an example of how to use this utility to dump JIT'd objects in LLJIT.
* [JITLink] Refactor EH-frame handling to support eh-frames with existing relocs.Lang Hames2019-11-066-320/+537
| | | | | | | | | | | | | | | | | | Some targets (E.g. MachO/arm64) use relocations to fix some CFI record fields in the eh-frame section. When relocations are used the initial (pre-relocation) content of the eh-frame section can no longer be interpreted by following the eh-frame specification. This causes errors in the existing eh-frame parser. This patch moves eh-frame handling into two LinkGraph passes that are run after relocations have been parsed (but before they are applied). The first] pass breaks up blocks in the eh-frame section into per-CFI-record blocks, and the second parses blocks of (potentially multiple) CFI records and adds the appropriate edges to any CFI fields that do not have existing relocations. These passes can be run independently of one another. By handling eh-frame splitting/fixing with LinkGraph passes we can both re-use existing relocations for CFI record fields and avoid applying eh-frame fixups before parsing the section (which would complicate the linker and require extra temporary allocations of working memory).
* [Orc] Fix iterator usage after removeAlexandre Ganea2019-11-061-1/+4
| | | | Differential Revision: https://reviews.llvm.org/D69805
* [JITLink] Move block ownership from LinkGraph to Section.Lang Hames2019-10-301-4/+0
| | | | This enables easy iteration over blocks in a specific section.
* [JITLink] Add a utility for splitting blocks at a given index.Lang Hames2019-10-301-0/+79
| | | | | | | | LinkGraph::splitBlock will split a block at a given index, returning a new block covering the range [ 0, index ) and modifying the original block to cover the range [ index, original-block-size ). Block addresses, content, edges and symbols will be updated as necessary. This utility will be used in upcoming improvements to JITLink's eh-frame support.
* Break out OrcError and RPCChris Bieneman2019-10-298-8/+34
| | | | | | | | | | | | | | | | | | | Summary: When createing an ORC remote JIT target the current library split forces the target process to link large portions of LLVM (Core, Execution Engine, JITLink, Object, MC, Passes, RuntimeDyld, Support, Target, and TransformUtils). This occurs because the ORC RPC interfaces rely on the static globals the ORC Error types require, which starts a cycle of pulling in more and more. This patch breaks the ORC RPC Error implementations out into an "OrcError" library which only depends on LLVM Support. It also pulls the ORC RPC headers into their own subdirectory. With this patch code can include the Orc/RPC/*.h headers and will only incur link dependencies on LLVMOrcError and LLVMSupport. Reviewers: lhames Reviewed By: lhames Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68732
* [JITLink] Tighten section sorting criteria to fix a flaky test case.Lang Hames2019-10-281-1/+3
| | | | | | | | | | Sections may have zero size and zero-sized sections may share a start address with other zero-sized sections. For the section overlap test to function correctly zero-sized sections must be ordered before any non-zero sized ones. This should fix the intermittent failures in the test/ExecutionEngine/JITLink/X86/MachO_zero_fill_alignment.s test case that have been observed on some builders.
* [llvm/Object] - Make ELFObjectFile::getRelocatedSection return ↵George Rimar2019-10-212-4/+23
| | | | | | | | | | | | | Expected<section_iterator> It returns just a section_iterator currently and have a report_fatal_error call inside. This change adds a way to return errors and handle them on caller sides. The patch also changes/improves current users and adds test cases. Differential revision: https://reviews.llvm.org/D69167 llvm-svn: 375408
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-191-0/+1
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* [Orc] Add a method for ObjectLinkingLayer to return ownership of object buffers.Lang Hames2019-10-151-0/+7
| | | | | | | | | | | | | | | | RTDyldObjectLinkingLayer allowed clients to register a NotifyEmitted function to reclaim ownership of object buffers once they had been linked. This patch adds similar functionality to ObjectLinkingLayer: Clients can now optionally call the ObjectLinkingLayer::setReturnObjectBuffer method to register a function that will be called when discarding object buffers. If set, this function will be called to return ownership of the object regardless of whether the link succeeded or failed. Use cases for this function include debug dumping (it provides a way to dump all objects linked into JIT'd code) and object re-use (e.g. storing an object in a cache). llvm-svn: 374951
* [JITLink] Switch to slab allocation for InProcessMemoryManager, re-enable test.Lang Hames2019-10-151-10/+40
| | | | | | | | | | | | | | InProcessMemoryManager used to make separate memory allocation calls for each permission level (RW, RX, RO), which could lead to target-out-of-range errors if data and code were placed too far apart (this was the source of failures in the JITLink/AArch64 testcase when it was first landed). This patch updates InProcessMemoryManager to allocate a single slab which is subdivided between text and data. This should guarantee that accesses remain in-range provided that individual object files do not exceed 1Mb in size. This patch also re-enables the JITLink/AArch64 testcase. llvm-svn: 374948
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-151-1/+1
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
* [JITLink] Fix MachO/arm64 GOTPAGEOFF encoding.Lang Hames2019-10-111-2/+5
| | | | | | | | The original implementation failed to shift the immediate down. This should fix some of the bot failures due to r374476. llvm-svn: 374499
* Fix compilation warning due to typo.Michael Liao2019-10-101-1/+1
| | | | llvm-svn: 374479
* [JITLink] Add an initial implementation of JITLink for MachO/AArch64.Lang Hames2019-10-103-0/+737
| | | | | | | | | This implementation has support for all relocation types except TLV. Compact unwind sections are not yet supported, so exceptions/unwinding will not work. llvm-svn: 374476
* Second attempt to add iterator_range::empty()Jordan Rose2019-10-071-1/+1
| | | | | | | | | | | | Doing this makes MSVC complain that `empty(someRange)` could refer to either C++17's std::empty or LLVM's llvm::empty, which previously we avoided via SFINAE because std::empty is defined in terms of an empty member rather than begin and end. So, switch callers over to the new method as it is added. https://reviews.llvm.org/D68439 llvm-svn: 373935
* [JITLink] Silence GCC warnings. NFC.Martin Storsjo2019-10-041-1/+1
| | | | | | | | Use parentheses in an expression with mixed && and ||. Differential Revision: https://reviews.llvm.org/D68447 llvm-svn: 373779
* Fix MSVC "not all control paths return a value" warning. NFCI.Simon Pilgrim2019-10-041-0/+2
| | | | llvm-svn: 373730
* Fix MSVC "result of 32-bit shift implicitly converted to 64 bits" warning. NFCI.Simon Pilgrim2019-10-041-1/+1
| | | | llvm-svn: 373729
* [JITLink] Explicitly destroy bumpptr-allocated blocks to avoid a memory leak.Lang Hames2019-10-041-0/+6
| | | | llvm-svn: 373693
* [JITLink] Fix an unused variable warning.Lang Hames2019-10-041-3/+2
| | | | llvm-svn: 373692
* [JITLink] Switch from an atom-based model to a "blocks and symbols" model.Lang Hames2019-10-0415-1328/+1488
| | | | | | | | | | | | | | | | | | | | | | | | In the Atom model the symbols, content and relocations of a relocatable object file are represented as a graph of atoms, where each Atom represents a contiguous block of content with a single name (or no name at all if the content is anonymous), and where edges between Atoms represent relocations. If more than one symbol is associated with a contiguous block of content then the content is broken into multiple atoms and layout constraints (represented by edges) are introduced to ensure that the content remains effectively contiguous. These layout constraints must be kept in mind when examining the content associated with a symbol (it may be spread over multiple atoms) or when applying certain relocation types (e.g. MachO subtractors). This patch replaces the Atom model in JITLink with a blocks-and-symbols model. The blocks-and-symbols model represents relocatable object files as bipartite graphs, with one set of nodes representing contiguous content (Blocks) and another representing named or anonymous locations (Symbols) within a Block. Relocations are represented as edges from Blocks to Symbols. This scheme removes layout constraints (simplifying handling of MachO alt-entry symbols, and hopefully ELF sections at some point in the future) and simplifies some relocation logic. llvm-svn: 373689
* [Alignment][NFC] Remove unneeded llvm:: scoping on Align typesGuillaume Chatelet2019-09-271-3/+3
| | | | llvm-svn: 373081
* [Orc] Silence static analyzer dyn_cast<ConstantInt> null dereference ↵Simon Pilgrim2019-09-241-1/+1
| | | | | | warning. NFCI. llvm-svn: 372746
* [ExecutionEngine] Don't dereference a dyn_cast result. NFCI.Simon Pilgrim2019-09-161-2/+2
| | | | | | The static analyzer is warning about potential null dereferences of dyn_cast<> results - in these cases we can safely use cast<> directly as we know that these cases should all be the correct type, which is why its working atm and anyway cast<> will assert if they aren't. llvm-svn: 371998
* Add dependency from Orc to PassesSanjoy Das2019-09-131-2/+2
| | | | | | | | | | | | | | Summary: Orc uses registerFunctionAnalyses that's defined in Passes. Reviewers: dblaikie Subscribers: mcrosier, bixia, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67477 llvm-svn: 371898
* [Orc] Roll back ThreadPool to std::functionBenjamin Kramer2019-09-131-1/+3
| | | | | | MSVC doesn't allow move-only types in std::packaged_task. Boo. llvm-svn: 371844
* [Orc] Address the remaining move-capture FIXMEsBenjamin Kramer2019-09-135-24/+18
| | | | | | | This required spreading unique_function a bit more, which I think is a good thing. llvm-svn: 371843
* [Alignment] Move OffsetToAlignment to Alignment.hGuillaume Chatelet2019-09-121-1/+3
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, JDevlieghere, alexshap, rupprecht, jhenderson Subscribers: sdardis, nemanjai, hiraditya, kbarton, jakehehrlich, jrtc27, MaskRay, atanasyan, jsji, seiya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D67499 llvm-svn: 371742
* AArch64: support arm64_32, an ILP32 slice for watchOS.Tim Northover2019-09-124-2/+8
| | | | | | | | This is the main CodeGen patch to support the arm64_32 watchOS ABI in LLVM. FastISel is mostly disabled for now since it would generate incorrect code for ILP32. llvm-svn: 371722
* [ORCv2] - New Speculate Query ImplementationPraveen Velliengiri2019-08-272-56/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces, SequenceBBQuery - new heuristic to find likely next callable functions it tries to find the blocks with calls in order of execution sequence of Blocks. It still uses BlockFrequencyAnalysis to find high frequency blocks. For a handful of hottest blocks (plan to customize), the algorithm traverse and discovered the caller blocks along the way to Entry Basic Block and Exit Basic Block. It uses Block Hint, to stop traversing the already visited blocks in both direction. It implicitly assumes that once the block is visited during discovering entry or exit nodes, revisiting them again does not add much. It also branch probability info (cached result) to traverse only hot edges (planned to customize) from hot blocks. Without BPI, the algorithm mostly return's all the blocks in the CFG with calls. It also changes the heuristic queries, so they don't maintain states. Hence it is safe to call from multiple threads. It also implements, new instrumentation to avoid jumping into JIT on every call to the function with the help _orc_speculate.decision.block and _orc_speculate.block. "Speculator Registration Mechanism is also changed" - kudos to @lhames Open to review, mostly looking to change implementation of SequeceBBQuery heuristics with good data structure choices. Reviewers: lhames, dblaikie Reviewed By: lhames Subscribers: mgorny, hiraditya, mgrang, llvm-commits, lhames Tags: #speculative_compilation_in_orc, #llvm Differential Revision: https://reviews.llvm.org/D66399 llvm-svn: 370092
* [JITLink][ORC] Track eh-frame section size for registration/deregistration.Lang Hames2019-08-272-39/+56
| | | | | | | | | | | | | | | On MachO, processing of the eh-frame section should stop if the end of the __eh_frame section is reached, regardless of whether or not there is a null CFI length field at the end of the section. This patch tracks the eh-frame section size and threads it through the appropriate APIs so that processing can be terminated correctly. No testcase yet: This patch is all API plumbing (rather than modification of linked memory) which the existing infrastructure does not provide a way of testing. Committing without a testcase until I have an idea of how to write one. llvm-svn: 370074
* [JITLink] Don't under-align zero-fill sections.Lang Hames2019-08-271-26/+13
| | | | | | | If content sections have lower alignment than zero-fill sections then bump the overall segment alignment to avoid under-aligning the zero-fill sections. llvm-svn: 370072
* [ORC] Make sure that queries on emitted-but-not-ready symbols fail correctly.Lang Hames2019-08-261-110/+81
| | | | | | | | | | | | | | | | | In r369808 the failure scheme for ORC symbols was changed to make MaterializationResponsibility objects responsible for failing the symbols they represented. This simplifies error logic in the case where symbols are still covered by a MaterializationResponsibility, but left a gap in error handling: Symbols that have been emitted but are not yet ready (due to a dependence on some unemitted symbol) are not covered by a MaterializationResponsibility object. Under the scheme introduced in r369808 such symbols would be moved to the error state, but queries on those symbols were never notified. This led to deadlocks when such symbols were failed. This commit updates error logic to immediately fail queries on any symbol that has already been emitted if one of its dependencies fails. llvm-svn: 369976
* [ORC] Fix an overly aggressive assert.Lang Hames2019-08-261-3/+6
| | | | | | | | Symbols that have not been queried will not have MaterializingInfo entries, so remove the assert that all failed symbols should have these entries. Also updates the loop to only remove entries that were found earlier. llvm-svn: 369975
* [ORC] Remove query dependencies when symbols are resolved.Lang Hames2019-08-231-0/+1
| | | | | | | | | | If the dependencies are not removed then a late failure (one symbol covered by the query failing after others have already been resolved) can result in an attempt to detach the query from already finalized symbol, resulting in an assert/crash. This patch fixes the issue by removing query dependencies in JITDylib::resolve for symbols that meet the required state. llvm-svn: 369809
* [ORC] Fix a FIXME: Propagate errors to dependencies.Lang Hames2019-08-235-100/+339
| | | | | | | | | | | | | When symbols are failed (via MaterializationResponsibility::failMaterialization) any symbols depending on them will now be moved to an error state. Attempting to resolve or emit a symbol in the error state (via the notifyResolved or notifyEmitted methods on MaterializationResponsibility) will result in an error. If notifyResolved or notifyEmitted return an error due to failure of a dependence then the caller should log or discard the error and call failMaterialization to propagate the failure to any queries waiting on the symbols being resolved/emitted (plus their dependencies). llvm-svn: 369808
* [cmake] Link in LLVMPasses due to dependency by LLVMOrcJIT; NFCHubert Tong2019-08-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: rL367756 (f5c40cb) increases the dependency of LLVMOrcJIT on LLVMPasses. In particular, symbols defined in LLVMPasses that are referenced by the destructor of `PassBuilder` are now referenced by LLVMOrcJIT through `Speculation.cpp.o`. We believe that referencing symbols defined in LLVMPasses in the destructor of `PassBuilder` is valid, and that adding to the set of such symbols is legitimate. To support such cases, this patch adds LLVMPasses to the set of libraries being linked when linking in LLVMOrcJIT causes such symbols from LLVMPasses to be referenced. Reviewers: Whitney, anhtuyen, pree-jackie Reviewed By: pree-jackie Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66441 llvm-svn: 369310
* [ORC] fix use-after-free detected by -Wreturn-stack-addressMatthias Gehre2019-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: llvm/lib/ExecutionEngine/Orc/Layer.cpp:53:12: warning: returning address of local temporary object [-Wreturn-stack-address] In ``` StringRef IRMaterializationUnit::getName() const { [...] return TSM.withModuleDo( [](const Module &M) { return M.getModuleIdentifier(); }); ``` `getModuleIdentifier()` returns a `const std::string &`, but the implicit return type of the lambda is `std::string` by value, and thus the returned `StringRef` refers to a temporary `std::string`. Detect by annotating `llvm::StringRef` with `[[gsl::Pointer]]`. Reviewers: lhames, sgraenitz Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66440 llvm-svn: 369306
* [ORC] Remove some stray debugging output accidentally left in r368707Lang Hames2019-08-161-2/+0
| | | | llvm-svn: 369141
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1518-47/+47
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-147-27/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
* Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-147-51/+27
| | | | | | | | Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
* [llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar2019-08-147-27/+51
| | | | | | | | | | | | | | | | | | | | | | | SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
* [ORC] Refactor definition-generation, add a generator for static libraries.Lang Hames2019-08-132-13/+134
| | | | | | | | | | | | | | | | | This patch replaces the JITDylib::DefinitionGenerator typedef with a class of the same name, and adds support for attaching a sequence of DefinitionGeneration objects to a JITDylib. This patch also adds a new definition generator, StaticLibraryDefinitionGenerator, that can be used to add symbols fom a static library to a JITDylib. An object from the static library will be added (via a supplied ObjectLayer reference) whenever a symbol from that object is referenced. To enable testing, lli is updated to add support for the --extra-archive option when running in -jit-kind=orc-lazy mode. llvm-svn: 368707
* Move findBBwithCalls to the file it's used in to avoid unused functionEric Christopher2019-08-131-0/+24
| | | | | | warnings. llvm-svn: 368636
* Replace llvm::MutexGuard/UniqueLock with their standard equivalentsBenjamin Kramer2019-08-077-47/+47
| | | | | | | All supported platforms have <mutex> now, so we don't need our own copies any longer. No functionality change intended. llvm-svn: 368149
OpenPOWER on IntegriCloud