summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc
Commit message (Collapse)AuthorAgeFilesLines
* [ORC] Fix a missing move in ce2207abaf9.Lang Hames2020-01-291-1/+1
| | | | | | | | This should fix the build failure at http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/32524 and others. (cherry picked from commit e0a6093a744d16c90eafa62d7143ce41806b2466)
* [ORC] Add support for emulated TLS to ORCv2.Lang Hames2020-01-296-50/+96
| | | | | | | | | | | | | | | | | | | | | | | This commit adds a ManglingOptions struct to IRMaterializationUnit, and replaces IRCompileLayer::CompileFunction with a new IRCompileLayer::IRCompiler class. The ManglingOptions struct defines the emulated-TLS state (via a bool member, EmulatedTLS, which is true if emulated-TLS is enabled and false otherwise). The IRCompileLayer::IRCompiler class wraps an IRCompiler (the same way that the CompileFunction typedef used to), but adds a method to return the IRCompileLayer::ManglingOptions that the compiler will use. These changes allow us to correctly determine the symbols that will be produced when a thread local global variable defined at the IR level is compiled with or without emulated TLS. This is required for ORCv2, where MaterializationUnits must declare their interface up-front. Most ORCv2 clients should not require any changes. Clients writing custom IR compilers will need to wrap their compiler in an IRCompileLayer::IRCompiler, rather than an IRCompileLayer::CompileFunction, however this should be a straightforward change (see modifications to CompileUtils.* in this patch for an example). (cherry picked from commit ce2207abaf9a925b35f15ef92aaff6b301ba6d22)
* [ORC] Add weak symbol support to defineMaterializing, fix for PR40074.Lang Hames2020-01-293-28/+96
| | | | | | | | | | | | | | | | | | The MaterializationResponsibility::defineMaterializing method allows clients to add new definitions that are in the process of being materialized to the JIT. This patch adds support to defineMaterializing for symbols with weak linkage where the new definitions may be rejected if another materializer concurrently defines the same symbol. If a weak symbol is rejected it will not be added to the MaterializationResponsibility's responsibility set. Clients can check for membership in the responsibility set via the MaterializationResponsibility::getSymbols() method before resolving any such weak symbols. This patch also adds code to RTDyldObjectLinkingLayer to tag COFF comdat symbols introduced during codegen as weak, on the assumption that these are COFF comdat constants. This fixes http://llvm.org/PR40074. (cherry picked from commit 84217ad66115cc31b184374a03c8333e4578996f)
* [ORC] Fix argv handling in runAsMain / lli.Lang Hames2020-01-111-1/+1
| | | | | | | | This fixes an off-by-one error in the argc value computed by runAsMain, and switches lli back to using the input bitcode (rather than the string "lli") as the effective program name. Thanks to Stefan Graenitz for spotting the bug.
* [NFC][ORC] Fix typos and whitespaces in commentsStefan Gränitz2020-01-031-1/+1
|
* [NFC] Fixes -Wrange-loop-analysis warningsMark de Wever2020-01-011-1/+1
| | | | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857
* [ORC] De-register eh-frames in the RTDyldObjectLinkingLayer destructor.Lang Hames2019-12-201-0/+6
| | | | | This matches the behavior of the legacy layer, which automatically deregistered frames.
* [Orc][LLJIT] Re-apply 298e183e813 (use JITLink for LLJIT where supported).Lang Hames2019-12-191-3/+7
| | | | Patch d9220b580b3 fixed the underlying issue that casued 298e183e813 to fail.
* Revert "[Orc][LLJIT] Use JITLink even if a custom JITTargetMachineBuilder is ↵Lang Hames2019-12-181-7/+3
| | | | | | | | supplied." This reverts commit 298e183e813c884dd22816383405bae3ef9ef278. This commit caused some build failures -- reverting while I investigate.
* [Orc][LLJIT] Use JITLink even if a custom JITTargetMachineBuilder is supplied.Lang Hames2019-12-181-3/+7
| | | | | | LLJITBuilder will now use JITLink on supported platforms even if a custom JITTargetMachineBuilder is supplied, provided that neither the code model, nor the relocation model, nor the ObjectLinkingLayerCreator is set.
* [Orc][LLJIT] Automatically use JITLink for LLJIT on supported platforms.Lang Hames2019-12-151-0/+18
| | | | | | | | | JITLink (which underlies ObjectLinkingLayer) is a replacement for RuntimeDyld. It supports the native code model, and linker plugins that enable a wider range of features than RuntimeDyld. Currently only enabled for MachO/x86-64 and MachO/arm64. New architectures will be added as JITLink support for them is developed.
* [ORC] Make ObjectLinkingLayer own its jitlink::MemoryManager.Lang Hames2019-12-151-4/+4
| | | | | | | | This relieves ObjectLinkingLayer clients of the responsibility of holding the memory manager. This makes it easier to select between RTDyldObjectLinkingLayer (which already owned its memory manager factory) and ObjectLinkingLayer at runtime as clients aren't required to hold a jitlink::MemoryManager field just in case ObjectLinkingLayer is selected.
* [ORC] Remove the automagic Main JITDylib fram ExecutionSession.Lang Hames2019-12-053-13/+4
| | | | | | | | | | | | This patch removes the magic "main" JITDylib from ExecutionEngine. The main JITDylib was created automatically at ExecutionSession construction time, and all subsequently created JITDylibs were added to the main JITDylib's links-against list by default. This saves a couple of lines of boilerplate for simple JIT setups, but this isn't worth introducing magical behavior for. ORCv2 clients should now construct their own main JITDylib using ExecutionSession::createJITDylib and set up its linkages manually using JITDylib::setSearchOrder (or related methods in JITDylib).
* [ORC] Add a runAsMain utility function to ExecutionUtils.Lang Hames2019-12-021-0/+26
| | | | | | | | | | | The runAsMain function takes a pointer to a function with a standard C main signature, int(*)(int, char*[]), and invokes it using the given arguments and program name. The arguments are copied into writable temporary storage as required by the C and C++ specifications, so runAsMain safe to use when calling main functions that modify their arguments in-place. This patch also uses the new runAsMain function to replace hand-rolled versions in lli, llvm-jitlink, and the SpeculativeJIT example.
* [Orc] Add setters for target options and features to JITTargetMachineBuilder.Lang Hames2019-12-021-3/+1
| | | | Also remove redundant feature initialization steps from the detectHost method.
* [ORC][JITLink] Add support for weak references, and improve handling of staticLang Hames2019-11-289-379/+427
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libraries. This patch substantially updates ORCv2's lookup API in order to support weak references, and to better support static archives. Key changes: -- Each symbol being looked for is now associated with a SymbolLookupFlags value. If the associated value is SymbolLookupFlags::RequiredSymbol then the symbol must be defined in one of the JITDylibs being searched (or be able to be generated in one of these JITDylibs via an attached definition generator) or the lookup will fail with an error. If the associated value is SymbolLookupFlags::WeaklyReferencedSymbol then the symbol is permitted to be undefined, in which case it will simply not appear in the resulting SymbolMap if the rest of the lookup succeeds. Since lookup now requires these flags for each symbol, the lookup method now takes an instance of a new SymbolLookupSet type rather than a SymbolNameSet. SymbolLookupSet is a vector-backed set of (name, flags) pairs. Clients are responsible for ensuring that the set property (i.e. unique elements) holds, though this is usually simple and SymbolLookupSet provides convenience methods to support this. -- Lookups now have an associated LookupKind value, which is either LookupKind::Static or LookupKind::DLSym. Definition generators can inspect the lookup kind when determining whether or not to generate new definitions. The StaticLibraryDefinitionGenerator is updated to only pull in new objects from the archive if the lookup kind is Static. This allows lookup to be re-used to emulate dlsym for JIT'd symbols without pulling in new objects from archives (which would not happen in a normal dlsym call). -- JITLink is updated to allow externals to be assigned weak linkage, and weak externals now use the SymbolLookupFlags::WeaklyReferencedSymbol value for lookups. Unresolved weak references will be assigned the default value of zero. Since this patch was modifying the lookup API anyway, it alo replaces all of the "MatchNonExported" boolean arguments with a "JITDylibLookupFlags" enum for readability. If a JITDylib's associated value is JITDylibLookupFlags::MatchExportedSymbolsOnly then the lookup will only match against exported (non-hidden) symbols in that JITDylib. If a JITDylib's associated value is JITDylibLookupFlags::MatchAllSymbols then the lookup will match against any symbol defined in the JITDylib.
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* 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.
* [Orc] Fix iterator usage after removeAlexandre Ganea2019-11-061-1/+4
| | | | Differential Revision: https://reviews.llvm.org/D69805
* Break out OrcError and RPCChris Bieneman2019-10-294-173/+2
| | | | | | | | | | | | | | | | | | | 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
* 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
* [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
* 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] Switch from an atom-based model to a "blocks and symbols" model.Lang Hames2019-10-042-105/+92
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [Orc] Silence static analyzer dyn_cast<ConstantInt> null dereference ↵Simon Pilgrim2019-09-241-1/+1
| | | | | | warning. NFCI. llvm-svn: 372746
* 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-133-13/+9
| | | | | | | This required spreading unique_function a bit more, which I think is a good thing. llvm-svn: 371843
* AArch64: support arm64_32, an ILP32 slice for watchOS.Tim Northover2019-09-122-1/+4
| | | | | | | | 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-271-30/+33
| | | | | | | | | | | | | | | 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
* [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-159-28/+28
| | | | | | | | 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
* [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
* Re-land D65760/r367944 Diego Caballero2019-08-061-1/+15
| | | | | | Fixed most vexing parse ambiguation. llvm-svn: 368055
* Reverting D65760/r367944 due to buildbot failure.Puyan Lotfi2019-08-051-15/+1
| | | | | | | | http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/15952/steps/build/logs/stdio JITTargetMachineBuilder.cpp fails to build. llvm-svn: 367954
* [ORC] Add CPU name and sub-target features to detectHostDiego Caballero2019-08-051-1/+15
| | | | | | | | | This commit adds host CPU name and sub-target features to the `JITTargetMachineBuilder` created by `JITTargetMachineBuilder::detectHost()`. Differential Revision: https://reviews.llvm.org/D65760 llvm-svn: 367944
* [ORC] Work around broken GCC/libstdc++ by adding an explicit conversion.Lang Hames2019-08-051-1/+4
| | | | | | This should fix the bots that have been failing due to r367712. llvm-svn: 367921
* Speculative CompilationPraveen Velliengiri2019-08-035-6/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ORC] Remove Speculator Variants for Different Program Representations [ORC] Block Freq Analysis Speculative Compilation with Naive Block Frequency Add Applications to OrcSpeculation ORC v2 with Block Freq Query & Example Deleted BenchMark Programs Signed-off-by: preejackie <praveenvelliengiri@gmail.com> ORCv2 comments resolved [ORCV2] NFC ORCv2 NFC [ORCv2] Speculative compilation - CFGWalkQuery ORCv2 Adapting IRSpeculationLayer to new locking scheme llvm-svn: 367756
* [ORC] Remove a dead method.Lang Hames2019-08-021-7/+0
| | | | llvm-svn: 367716
OpenPOWER on IntegriCloud