[ORC] Introduce LazyReexportsManager, JITLinkTrampolines, ORC-RT base… #118923
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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.
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/17/builds/4446 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/51/builds/7283 Here is the relevant piece of the build log for the reference |
lhames
added a commit
that referenced
this pull request
Dec 7, 2024
…118923)" This reverts commit 570ecdc while I investigate bot failures, e.g. https://lab.llvm.org/buildbot/#/builders/17/builds/4446.
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/143/builds/3963 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/146/builds/1782 Here is the relevant piece of the build log for the reference |
lhames
added a commit
that referenced
this pull request
Dec 9, 2024
This reapplies 570ecdc, which was reverted in 6073dd9 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.
lhames
added a commit
that referenced
this pull request
Dec 9, 2024
…ith fixes" This reverts commit 41652c6 while I investigate more bot failures.
broxigarchen
pushed a commit
to broxigarchen/llvm-project
that referenced
this pull request
Dec 10, 2024
llvm#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 llvm#1>, <implementation symbol llvm#1> ), ( <entry point symbol llvm#2>, <implementation symbol llvm#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.
broxigarchen
pushed a commit
to broxigarchen/llvm-project
that referenced
this pull request
Dec 10, 2024
…lvm#118923)" This reverts commit 570ecdc while I investigate bot failures, e.g. https://lab.llvm.org/buildbot/#/builders/17/builds/4446.
broxigarchen
pushed a commit
to broxigarchen/llvm-project
that referenced
this pull request
Dec 10, 2024
…fixes This reapplies 570ecdc, which was reverted in 6073dd9 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.
broxigarchen
pushed a commit
to broxigarchen/llvm-project
that referenced
this pull request
Dec 10, 2024
…" with fixes" This reverts commit 41652c6 while I investigate more bot failures.
broxigarchen
pushed a commit
to broxigarchen/llvm-project
that referenced
this pull request
Dec 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…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:
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:
Given an ObjectLinkingLayer and PlatformJD (JITDylib containing the ORC runtime), setup is just:
after which lazy reexports can be introduced with:
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.