Revision tags: llvmorg-21-init |
|
#
212cdc9a |
| 24-Jan-2025 |
Lang Hames <lhames@gmail.com> |
Revert "[ORC] Enable JIT support for the compact-unwind frame info format..."
This reverts 4f0325873faccfbe171bae4babceb65975ca892e and follow-up patches (see below) while I investigate some ongoing
Revert "[ORC] Enable JIT support for the compact-unwind frame info format..."
This reverts 4f0325873faccfbe171bae4babceb65975ca892e and follow-up patches (see below) while I investigate some ongoing failures on the buildbots.
---
Revert "[clang-repl] Try to XFAIL testcase on arm32 without affecting arm64 darwin."
This reverts commit fd174f0ff3e793fe96a6663b1488ed159cfe042f.
Revert "[clang-repl] The simple-exception test now passes on arm64-darwin."
This reverts commit c9bc242e387f4a4a3dfcd86561f3ec0ca8a72d62.
Revert "[ORC] Destroy defunct MaterializationUnits outside the session lock."
This reverts commit a001cc0e6cdcfa672b8aff9ce6d14782bb96356a.
Revert "[ORC] Add explicit narrowing casts to fix build errors."
This reverts commit 26fc07d5d88760ad659599184fd10181287d2d9e.
Revert "[ORC] Enable JIT support for the compact-unwind frame info format on Darwin."
This reverts commit 4f0325873faccfbe171bae4babceb65975ca892e.
show more ...
|
#
4f032587 |
| 22-Jan-2025 |
Lang Hames <lhames@gmail.com> |
[ORC] Enable JIT support for the compact-unwind frame info format on Darwin.
For Darwin/arm64 (including Apple Silicon Macs) this will enable exception handling and stack unwinding in JIT'd code.
D
[ORC] Enable JIT support for the compact-unwind frame info format on Darwin.
For Darwin/arm64 (including Apple Silicon Macs) this will enable exception handling and stack unwinding in JIT'd code.
Darwin supports two unwind-info formats: DWARF eh-frames and compact-unwind. On Darwin/x86-64 compilers usually produce both by default, and ORC supported exceptions and unwinding via eh-frames (same as on Linux), discarding the redundant compact-unwind info. On Darwin/arm64 compilers typically default to producing compact-unwind only, with DWARF eh-frames as a fallback for functions that can't be described in compact-unwind. Since ORC did not previously support the compact-unwind format and eh-frames were not present ORC was unable to handle exceptions or unwinding by default in Darwin/arm64 JIT'd code.
This patch enables support for the compact-unwind-info format, and contains three major moving parts:
(1) The JITLink CompactUnwindManager class is responsible for transforming the __compact_unwind records produced by the linker into the __unwind_info tables that libunwind parses during unwinding. To enable this the CompactUnwindManager class provides three JITLink passes: The prepareForPrune pass that splits the __compact_unwind section into single-record blocks, allowing unused records to be dead-stripped; the processAndReserveUnwindInfo pass that reserves space for the final __unwind_info section, and the writeUnwindInfo pass that writes the __unwind_info section.
(2) The OrcTargetProcess UnwindInfoManager class maintains a table of registered JIT'd __unwind_info and __eh_frame sections, and handles requests from libunwind for unwind info sections (by registering a callback with libunwind's __unw_add_find_dynamic_unwind_sections function).
(3) The Orc UnwindInfoRegistrationPlugin, which scans LinkGraphs for __unwind_info and __eh_frame sections to register with the UnwindInfoManager.
This commit adds the CompactUnwindManager passes to the default JITLink pipelines for Darwin/arm64 and Darwin/x86-64, and UnwindInfoManager intances to the SelfExecutorProcessControl class (when built for apple platforms) and the llvm-jitlink-executor tool.
The LLJIT class will now create an UnwindInfoRegistrationPlugin when targeting a process running on Darwin if it detects that an UnwindInfoManager is available to handle the registrations.
The ORC runtime macho_platform class already supported libunwind callbacks, so out-of-process execution and unwinding support will work when loading the ORC runtime.
The llvm-jitlink tool will only support compact-unwind when the orc-runtime is loaded, as the UnwindInfoRegistrationPlugin requires access to an IR compiler to load a helper module and llvm-jitlink does not provide an IR compiler.
show more ...
|
Revision tags: llvmorg-19.1.7 |
|
#
4eaff6c5 |
| 14-Jan-2025 |
Lang Hames <lhames@gmail.com> |
[JITLink] Use target triple for LinkGraph pointer size and endianness.
Removes LinkGraph's PointerSize and Endianness members and uses the triple to find these values instead.
Also removes some red
[JITLink] Use target triple for LinkGraph pointer size and endianness.
Removes LinkGraph's PointerSize and Endianness members and uses the triple to find these values instead.
Also removes some redundant Triple copies.
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
2ccf7ed2 |
| 05-Dec-2024 |
Jared Wyles <jared.wyles@gmail.com> |
[JITLink] Switch to SymbolStringPtr for Symbol names (#115796)
Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning
on the boundary between JITLink and ORC, and allows p
[JITLink] Switch to SymbolStringPtr for Symbol names (#115796)
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>
show more ...
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1 |
|
#
255870d7 |
| 19-Sep-2024 |
Lang Hames <lhames@gmail.com> |
[JITLink] Update splitBlock to support splitting into multiple blocks.
LinkGraph::splitBlock used to take a single split-point to split a Block into two. In the common case where a block needs to be
[JITLink] Update splitBlock to support splitting into multiple blocks.
LinkGraph::splitBlock used to take a single split-point to split a Block into two. In the common case where a block needs to be split repeatedly (e.g. in eh-frame and compact-unwind sections), iterative calls to splitBlock could lead to poor performance as symbols and edges are repeatedly shuffled to new blocks.
This commit updates LinkGraph::splitBlock to take a sequence of split offsets, allowing a block to be split into an arbitrary number of new blocks. Internally, Symbols and Edges only need to be moved once (directly to whichever new block they will be associated with), leading to better performance.
On some large MachO object files in an out of tree project this change improved the performance of splitBlock by several orders of magnitude.
rdar://135820493
show more ...
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1 |
|
#
e7698a13 |
| 24-Jul-2024 |
Lang Hames <lhames@gmail.com> |
Re-apply "[ORC][JITLink] Treat common symbols as weak definitions." with fixes.
This reapplies 785d376d123, which was reverted in c49837f5f68 due to bot failures. The fix was to relax some asserts t
Re-apply "[ORC][JITLink] Treat common symbols as weak definitions." with fixes.
This reapplies 785d376d123, which was reverted in c49837f5f68 due to bot failures. The fix was to relax some asserts to allow common symbols to be resolved with either common or weak flags, rather than requiring one or the other.
show more ...
|
#
c49837f5 |
| 24-Jul-2024 |
Lang Hames <lhames@gmail.com> |
Revert "[ORC][JITLink] Treat common symbols as weak definitions."
This reverts commit 785d376d1231167688dd12f93c5c0a5d46cd4086 while I investigate some bot failures (e.g. https://lab.llvm.org/buildb
Revert "[ORC][JITLink] Treat common symbols as weak definitions."
This reverts commit 785d376d1231167688dd12f93c5c0a5d46cd4086 while I investigate some bot failures (e.g. https://lab.llvm.org/buildbot/#/builders/3/builds/1983).
show more ...
|
#
785d376d |
| 24-Jul-2024 |
Lang Hames <lhames@gmail.com> |
[ORC][JITLink] Treat common symbols as weak definitions.
Duplicate common definitions should be coaleseced, rather than being treated as duplicate definitions. Strong definitions should override com
[ORC][JITLink] Treat common symbols as weak definitions.
Duplicate common definitions should be coaleseced, rather than being treated as duplicate definitions. Strong definitions should override common definitions.
rdar://132314264
show more ...
|
Revision tags: llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
586ecdf2 |
| 12-Dec-2023 |
Kazu Hirata <kazu@google.com> |
[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::
[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3 |
|
#
4a0ccfa8 |
| 13-Oct-2023 |
Kazu Hirata <kazu@google.com> |
Use llvm::endianness::{big,little,native} (NFC)
Note that llvm::support::endianness has been renamed to llvm::endianness while becoming an enum class as opposed to an enum. This patch replaces suppo
Use llvm::endianness::{big,little,native} (NFC)
Note that llvm::support::endianness has been renamed to llvm::endianness while becoming an enum class as opposed to an enum. This patch replaces support::{big,little,native} with llvm::endianness::{big,little,native}.
show more ...
|
#
a9d50568 |
| 11-Oct-2023 |
Kazu Hirata <kazu@google.com> |
Use llvm::endianness (NFC)
Now that llvm::support::endianness has been renamed to llvm::endianness, we can use the shorter form. This patch replaces support::endianness with llvm::endianness.
|
Revision tags: llvmorg-17.0.2 |
|
#
e994f84c |
| 28-Sep-2023 |
Lang Hames <lhames@gmail.com> |
[ORC] Rename MemLifetimePolicy to MemLifetime.
The *Policy suffix came from the earlier MemAllocPolicy type, where it was included to distinguish the type from a memory-allocation operation. MemLife
[ORC] Rename MemLifetimePolicy to MemLifetime.
The *Policy suffix came from the earlier MemAllocPolicy type, where it was included to distinguish the type from a memory-allocation operation. MemLifetime is a noun already, so the *Policy suffix is just dead weight now.
show more ...
|
Revision tags: llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3 |
|
#
94239712 |
| 14-Aug-2023 |
Eymen Ünay <eymenunay@outlook.com> |
Fix typos in comments of ExecutionEngine (NFC)
Reviewed By: sgraenitz
Differential Revision: https://reviews.llvm.org/D157226
|
Revision tags: llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
52b88457 |
| 27-Jun-2023 |
Job Noorman <jnoorman@igalia.com> |
[JITLink] Use SubtargetFeatures to store features in LinkGraph
D149522 introduced target features to LinkGraph. However, to avoid a public dependency on MC, the features were stored in a std::vector
[JITLink] Use SubtargetFeatures to store features in LinkGraph
D149522 introduced target features to LinkGraph. However, to avoid a public dependency on MC, the features were stored in a std::vector instead of using SubtargetFeatures directly.
Since SubtargetFeatures was moved from MC to TargetParser (D150549), we can now use it directly to store the features. This patch implements that and removes the (private) dependency on MC.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D153749
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
348d0a6b |
| 17-May-2023 |
Job Noorman <jnoorman@igalia.com> |
[JITLink] Add target features to LinkGraph
This patch adds SubtargetFeatures to LinkGraph. Similar to Triple, some targets might use this information while linking.
One example, and the reason this
[JITLink] Add target features to LinkGraph
This patch adds SubtargetFeatures to LinkGraph. Similar to Triple, some targets might use this information while linking.
One example, and the reason this patch was written, is linker relaxation on RISC-V: different relaxations are possible depending on if the C extension is enabled.
Note that the features are stored as `std::vector<std::string>` to prevent a public dependency on MC. There is still a private dependency to be able to convert SubtargetFeatures to a vector.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D149522
show more ...
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1 |
|
#
0b7e16af |
| 17-Mar-2023 |
Lang Hames <lhames@gmail.com> |
Re-apply "[JITLink][ORC] Rename MemDeallocPolicy to MemLifetime..." with fixes.
This reapplies 2cc64df0bd6a802eab592dbc282463c3e4a4281c, which was reverted in 5379c46d490640bfa80283e00240b6f1006092b
Re-apply "[JITLink][ORC] Rename MemDeallocPolicy to MemLifetime..." with fixes.
This reapplies 2cc64df0bd6a802eab592dbc282463c3e4a4281c, which was reverted in 5379c46d490640bfa80283e00240b6f1006092b4 due to bot failures.
The new patch contains fixes to ELFLinkGraphBuilder.h to better handle non-SHT_ALLOC sections (these were being accidentally skipped in the previous patch), and to skip SHT_NULL sections.
show more ...
|
#
5379c46d |
| 17-Mar-2023 |
Lang Hames <lhames@gmail.com> |
Revert "[JITLink][ORC] Rename MemDeallocPolicy to MemLifetimePolicy, add ..."
This reverts commit 2cc64df0bd6a802eab592dbc282463c3e4a4281c while I investigate bot failures (e.g. https://lab.llvm.org
Revert "[JITLink][ORC] Rename MemDeallocPolicy to MemLifetimePolicy, add ..."
This reverts commit 2cc64df0bd6a802eab592dbc282463c3e4a4281c while I investigate bot failures (e.g. https://lab.llvm.org/buildbot/#/builders/3/builds/23081).
show more ...
|
Revision tags: llvmorg-16.0.0 |
|
#
2cc64df0 |
| 16-Mar-2023 |
Lang Hames <lhames@gmail.com> |
[JITLink][ORC] Rename MemDeallocPolicy to MemLifetimePolicy, add NoAlloc option.
The original MemDeallocPolicy had two options: * Standard: allocated memory lives until deallocated or abandoned. * F
[JITLink][ORC] Rename MemDeallocPolicy to MemLifetimePolicy, add NoAlloc option.
The original MemDeallocPolicy had two options: * Standard: allocated memory lives until deallocated or abandoned. * Finalize: allocated memory lives until all finalize actions have been run, then is destroyed.
This patch introduces a new 'NoAlloc' option. NoAlloc indicates that the section should be ignored by the JITLinkMemoryManager -- the memory manager should allocate neither working memory nor executor address space to blocks in NoAlloc sections. The NoAlloc option is intended to support metadata sections (e.g. debug info) that we want to keep in the graph and have fixed up if necessary, but don't want allocated or transmitted to the executor (or we want that allocation and transmission to be managed manually by plugins).
Since NoAlloc blocks are ignored by the JITLinkMemoryManager they will not have working memory allocated to them by default post-allocation. Clients wishing to modify the content of a block in a NoAlloc section should call `Block::getMutableMemory(LinkGraph&)` to get writable memory allocated on the LinkGraph's allocator (this memory will exist for the lifetime of the graph). If no client requests mutable memory prior to the fixup phase then the generic link algorithm will do so when it encounters the first edge in any given block.
Addresses of blocks in NoAlloc sections are initialized by the LinkGraph creator (a LinkGraphBuilder, if the graph is generated from an object file), and should not be modified by the JITLinkMemoryManager. Plugins are responsible for updating addresses if they add/remove content from these sections. The meaning of addresses in NoAlloc-sections is backend/plugin defined, but for fixup purposes they will be treated the same as addresses in Standard/Finalize sections. References from Standard/Finalize sections to NoAlloc sections are expected to be common (these represent metadata tracking executor addresses). References from NoAlloc sections to Standard/Finalize sections are expected to be rare/non-existent (they would represent JIT'd code / data tracking metadata in the controller, which would be surprising). LinkGraphBuilders and specific backends may impose additional constraints on edges between Standard/Finalize and NoAlloc sections where required for correctness.
Differential Revision: https://reviews.llvm.org/D146183
show more ...
|
Revision tags: llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3 |
|
#
10b5fec2 |
| 11-Feb-2023 |
Lang Hames <lhames@gmail.com> |
[JITLink][ORC] Add LinkGraph::allocateCString method.
Renames the existing allocateString method to allocateContent and adds a pair of allocateCString methods.
The previous allocateString method di
[JITLink][ORC] Add LinkGraph::allocateCString method.
Renames the existing allocateString method to allocateContent and adds a pair of allocateCString methods.
The previous allocateString method did not include a null-terminator. It behaved the same as allocateContent except with a Twine input, rather than an ArrayRef<char>. Renaming allocateString to allocateBuffer (overloading the existing method) makes this clearer.
The new allocateCString methods allocate the given content plus a null-terminator character, and return a buffer covering both the string and null-terminator. This makes them suitable for creating c-string content for jitlink::Blocks.
Existing users of the old allocateString method have been updated to use the new allocateContent overload.
show more ...
|
#
9eccc6cc |
| 11-Feb-2023 |
Lang Hames <lhames@gmail.com> |
[JITLink] Add a predicate to test for C-string blocks.
|
Revision tags: llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1 |
|
#
2667be0e |
| 28-Jan-2023 |
Lang Hames <lhames@gmail.com> |
[JITLink][MachO] Error on N_EXT symbols with illegal string-table index 0.
Index 0 is reserved for anonymous symbols, which can't have the N_EXT bit set (since N_EXT means non-local scope, and non-l
[JITLink][MachO] Error on N_EXT symbols with illegal string-table index 0.
Index 0 is reserved for anonymous symbols, which can't have the N_EXT bit set (since N_EXT means non-local scope, and non-local scope requires a name).
show more ...
|
Revision tags: llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6 |
|
#
e80118ee |
| 26-Nov-2022 |
Kazu Hirata <kazu@google.com> |
[JITLink] Use std::optional in MachOLinkGraphBuilder.cpp (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-ha
[JITLink] Use std::optional in MachOLinkGraphBuilder.cpp (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2 |
|
#
d3d9f7ca |
| 02-Oct-2022 |
Lang Hames <lhames@gmail.com> |
[ORC][JITLink] Move MemoryFlags.h (MemProt, AllocGroup,...) from JITLink to ORC.
Moving these types to OrcShared eliminates the need for the separate WireProtectionFlags type.
|
#
ffe2dda2 |
| 27-Sep-2022 |
Lang Hames <lhames@gmail.com> |
[ORC][JITLink] Retain Weak flags in JITDylib interfaces, propagate to LinkGraph.
Previously we stripped Weak flags from JITDylib symbol table entries once they were resolved (there was no particular
[ORC][JITLink] Retain Weak flags in JITDylib interfaces, propagate to LinkGraph.
Previously we stripped Weak flags from JITDylib symbol table entries once they were resolved (there was no particularly good reason for this). Now we want to retain them and query them when setting the Linkage on external symbols in LinkGraphs during symbol resolution (this was the motivation for 75404e9ef88). Making weak linkage of external definitions discoverable in the LinkGraph will in turn allow future plugins to implement correct handling for them (by recording locations that depend on exported weak definitions and pointing all of these at one chosen definition at runtime).
show more ...
|
#
75404e9e |
| 26-Sep-2022 |
Lang Hames <lhames@gmail.com> |
[JITLink] Introduce new weakly-referenced concept separate from linkage.
Introduces two new methods on Symbol: isWeaklyReferenced and setWeaklyReferenced. These are now used to track/set whether an
[JITLink] Introduce new weakly-referenced concept separate from linkage.
Introduces two new methods on Symbol: isWeaklyReferenced and setWeaklyReferenced. These are now used to track/set whether an external symbol is weakly referenced, rather than having the Symbol's linkage set to weak.
This change is a first step towards proper handling of weak defs used across JITDylib boundaries: It frees up the Linkage field on external symbols so that it can be used to represent the linkage of the definition that the symbol resolves to. It is expected that Platform plugins will use this information to track locations that need to be updated if the selected weak definition changes (e.g. because JITDylibs were dlclosed and then dlopened again in a different order).
show more ...
|