|
Revision tags: llvmorg-21-init, 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, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, 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, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, 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.
|
|
Revision tags: llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3 |
|
| #
23d0e71f |
| 09-Aug-2022 |
Anubhab Ghosh <anubhabghosh.me@gmail.com> |
[Orc] Use IntervalMap to store free memory regions in MapperJITLinkMemoryManager
MapperJITLinkMemoryManager uses a free list to keep track of available
memory regions. Using an IntervalMap instead o
[Orc] Use IntervalMap to store free memory regions in MapperJITLinkMemoryManager
MapperJITLinkMemoryManager uses a free list to keep track of available
memory regions. Using an IntervalMap instead of vector allow automatic
coalescing of memory regions as they are freed.
Differential Revision: https://reviews.llvm.org/D131831
show more ...
|
| #
a31af321 |
| 12-Aug-2022 |
Anubhab Ghosh <anubhabghosh.me@gmail.com> |
Reapply [Orc] Properly deallocate mapped memory in MapperJITLinkMemoryManager
When memory is deallocated from MapperJITLinkMemoryManager deinitialize
actions are run through mapper and in case of In
Reapply [Orc] Properly deallocate mapped memory in MapperJITLinkMemoryManager
When memory is deallocated from MapperJITLinkMemoryManager deinitialize
actions are run through mapper and in case of InProcessMapper, memory
protections of the region are reset to read/write as they were previously
changed and can be reused in future.
Differential Revision: https://reviews.llvm.org/D131768
show more ...
|
| #
81801051 |
| 13-Aug-2022 |
Anubhab Ghosh <anubhabghosh.me@gmail.com> |
Revert "[Orc] Properly deallocate mapped memory in MapperJITLinkMemoryManager"
This reverts commit 143555b2ed30746fbcc8ff84e9cef4267688f110.
|
| #
143555b2 |
| 12-Aug-2022 |
Anubhab Ghosh <anubhabghosh.me@gmail.com> |
[Orc] Properly deallocate mapped memory in MapperJITLinkMemoryManager
When memory is deallocated from MapperJITLinkMemoryManager deinitialize
actions are run through mapper and in case of InProcessM
[Orc] Properly deallocate mapped memory in MapperJITLinkMemoryManager
When memory is deallocated from MapperJITLinkMemoryManager deinitialize
actions are run through mapper and in case of InProcessMapper, memory
protections of the region are reset to read/write as they were previously
changed and can be reused in future.
Differential Revision: https://reviews.llvm.org/D131768
show more ...
|
|
Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
1eee6de8 |
| 22-Jul-2022 |
Anubhab Ghosh <anubhabghosh.me@gmail.com> |
[Orc][JITLink] Slab based memory allocator to reduce RPC calls
Calling reserve() used to require an RPC call. This commit allows large
ranges of executor address space to be reserved. Subsequent cal
[Orc][JITLink] Slab based memory allocator to reduce RPC calls
Calling reserve() used to require an RPC call. This commit allows large
ranges of executor address space to be reserved. Subsequent calls to
reserve() will return subranges of already reserved address space while
there is still space available.
Differential Revision: https://reviews.llvm.org/D130392
show more ...
|
| #
4fcf8434 |
| 21-Jul-2022 |
Anubhab Ghosh <anubhabghosh.me@gmail.com> |
[ORC] Add a new MemoryMapper-based JITLinkMemoryManager implementation.
MapperJITLinkMemoryManager supports executor memory management using any
implementation of MemoryMapper to do the transfer suc
[ORC] Add a new MemoryMapper-based JITLinkMemoryManager implementation.
MapperJITLinkMemoryManager supports executor memory management using any
implementation of MemoryMapper to do the transfer such as InProcessMapper or
SharedMemoryMapper.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D129495
show more ...
|