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

Use llvm::find (NFC)

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

[ORC] Fix typo in 543790add86.

[ORC] More attempts to fix Windows bots after d3d9f7caf966.

Move getWindowsProtectionFlags inside namespace to make MemProt type accessible.

[ORC] Attempt to fix Windows bots after d3d9f7caf966.

That patch failed to include an update to the Windows side of
ExecutorSharedMemoryMapperService.

[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] Improve deintialize and shutdown logic

When deinitializing, the allocation needs to be removed from the
allocation list of its associated reservation so that remaining
allocations can be deini

[Orc] Improve deintialize and shutdown logic

When deinitializing, the allocation needs to be removed from the
allocation list of its associated reservation so that remaining
allocations can be deinitialized when releasing the reservation.

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

show more ...

[Orc] Reorder operations in ExecutorSharedMemoryMapperService shutdown

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

[ORC] Fix a warning about an unused variable on Windows. NFC.

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

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

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

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

Revert "[ORC] Fix compilation on mingw"

This reverts commit 46b1a7c5f9e6841016078d32728bb0d205336df5.

Parent commit breaks shared library build, reverting both commits.

[ORC] Fix compilation on mingw

Explicitly call the -W suffixed API functions when passing wchar based
strings.

[ORC] Add a shared-memory based orc::MemoryMapper.

This is an implementation of orc::MemoryMapper that maps shared memory
pages in both executor and controller process and writes directly to
them av

[ORC] Add a shared-memory based orc::MemoryMapper.

This is an implementation of orc::MemoryMapper that maps shared memory
pages in both executor and controller process and writes directly to
them avoiding transferring content over EPC. All allocations are properly
deinitialized automatically on the executor side at shutdown by the
ExecutorSharedMemoryMapperService.

Reviewed By: lhames

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

show more ...