summaryrefslogtreecommitdiff
path: root/llvm/lib/ExecutionEngine/Orc/LazyObjectLinkingLayer.cpp
AgeCommit message (Collapse)Author
2024-12-09Reapply "[ORC] Introduce LazyReexportsManager, ... (#118923)" with fixes.Lang Hames
This re-applies 570ecdcf8b4, which was reverted in 74e8a37ff32 due to bot failures. This commit renames sysv_resolve.cpp to resolve.cpp, which was the cause of the config errors.
2024-12-09Revert "Reapply "[ORC] Introduce LazyReexportsManager, … (#118923)" with ↵Lang Hames
fixes" This reverts commit 41652c6c92958a87b8505b9b1e6f008856e392ac while I investigate more bot failures.
2024-12-09Reapply "[ORC] Introduce LazyReexportsManager, … (#118923)" with fixesLang Hames
This reapplies 570ecdcf8b4, which was reverted in 6073dd923b8 due to bot failures. The test failures on Linux were fixed by: 1. Removing an overly restrictive assertion (query dependence on a symbol no longer implies a MaterializingInfo for that symbol) 2. Adding reentry and resolver files to the ORC runtime CMakeLists.txt for Linux. 3. Adding the __orc_rt_reentry -> __orc_rt_sysv_reentry alias to ELFNixPlatform.
2024-12-07Revert "[ORC] Introduce LazyReexportsManager, JITLinkTrampolines, … (#118923)"Lang Hames
This reverts commit 570ecdcf8b44aec853ce381a5f6b77222b041afa while I investigate bot failures, e.g. https://lab.llvm.org/buildbot/#/builders/17/builds/4446.
2024-12-07[ORC] Introduce LazyReexportsManager, JITLinkTrampolines, ORC-RT base… ↵Lang Hames
(#118923) …d reentry. These utilities provide new, more generic and easier to use support for lazy compilation in ORC. LazyReexportsManager is an alternative to LazyCallThroughManager. It takes requests for lazy re-entry points in the form of an alias map: lazy-reexports = { ( <entry point symbol #1>, <implementation symbol #1> ), ( <entry point symbol #2>, <implementation symbol #2> ), ... ( <entry point symbol #n>, <implementation symbol #n> ) } LazyReexportsManager then: 1. binds the entry points to the implementation names in an internal table. 2. creates a JIT re-entry trampoline for each entry point. 3. creates a redirectable symbol for each of the entry point name and binds redirectable symbol to the corresponding reentry trampoline. When an entry point symbol is first called at runtime (which may be on any thread of the JIT'd program) it will re-enter the JIT via the trampoline and trigger a lookup for the implementation symbol stored in LazyReexportsManager's internal table. When the lookup completes the entry point symbol will be updated (via the RedirectableSymbolManager) to point at the implementation symbol, and execution will proceed to the implementation symbol. Actual construction of the re-entry trampolines and redirectable symbols is delegated to an EmitTrampolines functor and the RedirectableSymbolsManager respectively. JITLinkReentryTrampolines.h provides a JITLink-based implementation of the EmitTrampolines functor. (AArch64 only in this patch, but other architectures will be added in the near future). Register state save and reentry functionality is added to the ORC runtime in the __orc_rt_sysv_resolve and __orc_rt_resolve_implementation functions (the latter is generic, the former will need custom implementations for each ABI and architecture to be supported, however this should be much less effort than the existing OrcABISupport approach, since the ORC runtime allows this code to be written as native assembly). The resulting system: 1. Works equally well for in-process and out-of-process JIT'd code. 2. Requires less boilerplate to set up. Given an ObjectLinkingLayer and PlatformJD (JITDylib containing the ORC runtime), setup is just: ```c++ auto RSMgr = JITLinkRedirectableSymbolManager::Create(OLL); if (!RSMgr) return RSMgr.takeError(); auto LRMgr = createJITLinkLazyReexportsManager(OLL, **RSMgr, PlatformJD); if (!LRMgr) return LRMgr.takeError(); ``` after which lazy reexports can be introduced with: ```c++ JD.define(lazyReexports(LRMgr, <alias map>)); ``` LazyObectLinkingLayer is updated to use this new method, but the LLVM-IR level CompileOnDemandLayer will continue to use LazyCallThroughManager and OrcABISupport until the new system supports a wider range of architectures and ABIs. The llvm-jitlink utility's -lazy option now uses the new scheme. Since it depends on the ORC runtime, the lazy-link.ll testcase and associated helpers are moved to the ORC runtime.
2024-12-06[JITLink] Switch to SymbolStringPtr for Symbol names (#115796)Jared Wyles
Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning on the boundary between JITLink and ORC, and allows pointer comparisons (rather than string comparisons) between Symbol names. This should improve the performance and readability of code that bridges between JITLink and ORC (e.g. ObjectLinkingLayer and ObjectLinkingLayer::Plugins). To enable use of SymbolStringPtr a std::shared_ptr<SymbolStringPool> is added to LinkGraph and threaded through to its construction sites in LLVM and Bolt. All LinkGraphs that are to have symbol names compared by pointer equality must point to the same SymbolStringPool instance, which in ORC sessions should be the pool attached to the ExecutionSession. --------- Co-authored-by: Lang Hames <lhames@gmail.com>
2024-11-18[ORC] Add LazyObjectLinkingLayer, lazy-linking support to llvm-jitlink (#116002)Lang Hames
LazyObjectLinkingLayer can be used to add object files that will not be linked into the executor unless some function that they define is called at runtime. (References to data members defined by these objects will still trigger immediate linking) To implement lazy linking, LazyObjectLinkingLayer uses the lazyReexports utility to construct stubs for each function in a given object file, and an ObjectLinkingLayer::Plugin to rename the function bodies at link-time. (Data symbols are not renamed) The llvm-jitlink utility is extended with a -lazy option that can be passed before input files or archives to add them using the lazy linking layer rather than the base ObjectLinkingLayer.