[ExecutionEngine] Remove unused includes (NFC) (#116749)

Identified with misc-include-cleaner.

[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial si

[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects.

show more ...

[z/OS] Implement shared memory handling for JIT (#89933)

Fix 'use of undeclared identifier' build errors for shm_ functions on
z/OS by implementing the functionality using shmget(), shmat(), and
s

[z/OS] Implement shared memory handling for JIT (#89933)

Fix 'use of undeclared identifier' build errors for shm_ functions on
z/OS by implementing the functionality using shmget(), shmat(), and
shmdt(). Use the BLAKE3 hash to map the name of the shared memory to a
key.

---------

Co-authored-by: Kai Nacke <kai.peter.nacke@ibm.com>

show more ...

[llvm][Support] Add and use errnoAsErrorCode (#84423)

LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare

[llvm][Support] Add and use errnoAsErrorCode (#84423)

LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare
differently if one is system and one is generic on POSIX systems.

This is even more of a problem on Windows where use of the system
category is just wrong, as that is for Windows errors, which have a
completely different mapping than POSIX/generic errors. This patch fixes
one instance of this mistake in `JSONTransport.cpp`.

This patch adds `errnoAsErrorCode()` which makes it so people do not
need to think about this issue in the future. It also cleans up a lot of
usage of `errno` in LLVM and Clang.

show more ...

[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 ...

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 ...

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 ...

[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 ...

Add void cast for preprocessor-conditionall-unused loop variable

Fixing -Wunused -Werror build on Android.

[Orc] Fix the SharedMemoryMapper dtor

As briefly discussed on https://reviews.llvm.org/rG1134d3a03facccd75efc5385ba46918bef94fcb6, fix the unintended copy while iterating on Reservations and add a m

[Orc] Fix the SharedMemoryMapper dtor

As briefly discussed on https://reviews.llvm.org/rG1134d3a03facccd75efc5385ba46918bef94fcb6, fix the unintended copy while iterating on Reservations and add a mutex guard, to be symmetric with other usages of Reservations.

Differential revision: https://reviews.llvm.org/D134212

show more ...

[ORC] Don't unnecessarily copy collection element.

[ORC][JITLink] Move MemoryFlags.h (MemProt, AllocGroup,...) from JITLink to ORC.

Moving these types to OrcShared eliminates the need for the separate
WireProtectionFlags type.

[ORC] Update mapper deinitialize functions to deinitialize in reverse order.

This updates the ExecutorSharedMemoryMapperService::deinitialize and
InProcessMemoryMapper::deinitialize methods to deini

[ORC] Update mapper deinitialize functions to deinitialize in reverse order.

This updates the ExecutorSharedMemoryMapperService::deinitialize and
InProcessMemoryMapper::deinitialize methods to deinitialize in reverse order,
bringing them into alignment with the behavior of
InProcessMemoryManager::deallocate and SimpleExecutorMemoryManager::deallocate.
Reverse deinitialization is required because later allocations can depend on
earlier ones.

This fixes failures in the ORC runtime test suite.

show more ...

[Orc] Take offset inside slab into account in SharedMemoryMapper

SharedMemoryMapper assumed each reservation will have its corresponding
allocations starting from the beginning. However with the int

[Orc] Take offset inside slab into account in SharedMemoryMapper

SharedMemoryMapper assumed each reservation will have its corresponding
allocations starting from the beginning. However with the introduction
of the slab allocator, there can be a possible offset from the start
from where the initialization is being performed.

This commit also simplifies the logic for finding the parent reservation
and makes the assert messages consistent.

show more ...

[Orc] Provide correct Reservation address for slab allocations

When slab allocator is used, the MappingBase is not necessarily
the same as the original reservation base as the allocation could
be a

[Orc] Provide correct Reservation address for slab allocations

When slab allocator is used, the MappingBase is not necessarily
the same as the original reservation base as the allocation could
be a part of the whole reservation.

In this case the original reservation address needs to be passed to
ExecutorSharedMemoryMapperService to associate the new allocation
with the original reservation.

Differential Revision: https://reviews.llvm.org/D132313

show more ...

[Orc] Only unmap shared memory in controller process destructor

By the time SharedMemoryMapper destructor is called, the RPC
connection is no longer available causing the release() call to
always fa

[Orc] Only unmap shared memory in controller process destructor

By the time SharedMemoryMapper destructor is called, the RPC
connection is no longer available causing the release() call to
always fail. Instead at this point only shared memory regions
can be unmapped safely.

Deinitializers are called and mapped memory is released at the
executor side by ExecutorSharedMemoryMapperService::shutdown()
instead. Memory can also be released earlier by calling release()
earlier before RPC connection is closed.

Differential Revision: https://reviews.llvm.org/D132313

show more ...

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 ...

Revert "[Orc] Properly deallocate mapped memory in MapperJITLinkMemoryManager"

This reverts commit 143555b2ed30746fbcc8ff84e9cef4267688f110.

[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 ...

[ORC] Actually propagate memory unmapping errors on Windows

This fixes warnings like these:

../lib/ExecutionEngine/Orc/MemoryMapper.cpp:364:9: warning: ignoring return value of function declare

[ORC] Actually propagate memory unmapping errors on Windows

This fixes warnings like these:

../lib/ExecutionEngine/Orc/MemoryMapper.cpp:364:9: warning: ignoring return value of function declared with 'warn_unused_result' attribute [-Wunused-result]
joinErrors(std::move(Err),
^~~~~~~~~~ ~~~~~~~~~~~~~~~

Differential Revision: https://reviews.llvm.org/D131056

show more ...

[Orc] Disable use of shared memory on Android

shm_open and shm_unlink are not available on Android. This commit
disables SharedMemoryMapper on Android until a better solution is
available.

https://

[Orc] Disable use of shared memory on Android

shm_open and shm_unlink are not available on Android. This commit
disables SharedMemoryMapper on Android until a better solution is
available.

https://android.googlesource.com/platform/bionic/+/refs/heads/master/docs/status.md
https://github.com/llvm/llvm-project/issues/56812

Differential Revision: https://reviews.llvm.org/D130814

show more ...

[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 ...

Re-re-apply 5acd47169884, Add a shared-memory based orc::MemoryMapper...

...with more fixes.

The original patch was reverted in 3e9cc543f22 due to bot failures caused by
a missing dependence on lib

Re-re-apply 5acd47169884, Add a shared-memory based orc::MemoryMapper...

...with more fixes.

The original patch was reverted in 3e9cc543f22 due to bot failures caused by
a missing dependence on librt. That issue was fixed in 32d8d23cd0, but that
commit also broke sanitizer bots due to a bug in SimplePackedSerialization:
empty ArrayRef<char>s triggered a zero-byte memcpy from a null source. The
ArrayRef<char> serialization issue was fixed in 67220c2ad7, and this patch has
also been updated with a new custom SharedMemorySegFinalizeRequest message that
should avoid serializing empty ArrayRefs in the first place.

https://reviews.llvm.org/D128544

show more ...

Revert "Re-apply 5acd47169884, Add a shared-memory based orc::MemoryMapper, with fixes."

This reverts commit 32d8d23cd0b2d4d010eb112dfe5216f11b2681f9.

Reason: Broke the UBSan buildbots. See more de

Revert "Re-apply 5acd47169884, Add a shared-memory based orc::MemoryMapper, with fixes."

This reverts commit 32d8d23cd0b2d4d010eb112dfe5216f11b2681f9.

Reason: Broke the UBSan buildbots. See more details on Phabricator:
https://reviews.llvm.org/D128544

show more ...

Re-apply 5acd47169884, Add a shared-memory based orc::MemoryMapper, with fixes.

The original commit was reverted in 3e9cc543f223 due to buildbot failures, which
should be fixed by the addition of de

Re-apply 5acd47169884, Add a shared-memory based orc::MemoryMapper, with fixes.

The original commit was reverted in 3e9cc543f223 due to buildbot failures, which
should be fixed by the addition of dependencies on librt.

Differential Revision: https://reviews.llvm.org/D128544

show more ...