Changes

Summary

  1. [Support] Convert BinaryStream class zoo to 64-bit offsets (details)
  2. [flang] Enforce array conformance in actual arguments to ELEMENTALs (details)
  3. Update LoopPredication test to fix buildbot failure. (details)
  4. [ORC] Add finalization & deallocation actions, SimpleExecutorMemoryManager class (details)
  5. [gn build] Port 78b083dbb725 (details)
  6. [compiler-rt][test] Add int128 requirement to TestCases/Misc/Linux/static-link.cpp (details)
Commit 646299d183ca72cbafd3a2d64629ce8cb3fcdd9d by thakis
[Support] Convert BinaryStream class zoo to 64-bit offsets

Most PDB fields on disk are 32-bit but describe the file in terms of MSF
blocks, which are 4 kiB by default.

So PDB files can be a bit larger than 4 GiB, and much larger if you create them
with a block size > 4 kiB.

This is a first (necessary, but by far not not sufficient) step towards
supporting such PDB files.  Now we don't truncate in-memory file offsets (which
are in terms of bytes, not in terms of blocks).

No effective behavior change. lld-link will still error out if it were to
produce PDBs > 4 GiB.

Differential Revision: https://reviews.llvm.org/D109923
The file was modifiedllvm/unittests/Support/BinaryStreamTest.cpp
The file was modifiedllvm/include/llvm/Support/BinaryItemStream.h
The file was modifiedllvm/lib/Support/BinaryStreamRef.cpp
The file was modifiedllvm/include/llvm/Support/BinaryStreamWriter.h
The file was modifiedllvm/include/llvm/Support/BinaryByteStream.h
The file was modifiedllvm/tools/llvm-pdbutil/LinePrinter.h
The file was modifiedllvm/unittests/DebugInfo/MSF/MappedBlockStreamTest.cpp
The file was modifiedllvm/include/llvm/DebugInfo/MSF/MappedBlockStream.h
The file was modifiedllvm/tools/llvm-pdbutil/LinePrinter.cpp
The file was modifiedllvm/lib/DebugInfo/MSF/MappedBlockStream.cpp
The file was modifiedllvm/include/llvm/Support/BinaryStreamReader.h
The file was modifiedllvm/lib/Support/BinaryStreamReader.cpp
The file was modifiedllvm/include/llvm/Support/BinaryStreamRef.h
The file was modifiedllvm/lib/Support/BinaryStreamWriter.cpp
The file was modifiedllvm/lib/DebugInfo/PDB/Native/NativeEnumInjectedSources.cpp
The file was modifiedllvm/include/llvm/Support/BinaryStream.h
Commit 19afc495dc2797803b3da7f0797f214483215bb8 by pklausler
[flang] Enforce array conformance in actual arguments to ELEMENTALs

When the shapes of actual arguments to ELEMENTAL procedures are
sufficiently well known during semantics, require them to conform.

Differential Revision: https://reviews.llvm.org/D109909
The file was modifiedflang/lib/Semantics/check-call.cpp
The file was addedflang/test/Semantics/call22.f90
Commit fe950cba8f463562072e196a01409425b6ca0d40 by dsuchkov
Update LoopPredication test to fix buildbot failure.

This patch updates tests added in 5f2b7879f16ad5023f0684febeb0a20f7d53e4a8.
The file was modifiedllvm/test/Transforms/LoopPredication/invalidate-analyses.ll
Commit 78b083dbb725e1ec568d1b8ee523f5f025d25798 by Lang Hames
[ORC] Add finalization & deallocation actions, SimpleExecutorMemoryManager class

Finalization and deallocation actions are a key part of the upcoming
JITLinkMemoryManager redesign: They generalize the existing finalization and
deallocate concepts (basically "copy-and-mprotect", and "munmap") to include
support for arbitrary registration and deregistration of parts of JIT linked
code. This allows us to register and deregister eh-frames, TLV sections,
language metadata, etc. using regular memory management calls with no additional
IPC/RPC overhead, which should both improve JIT performance and simplify
interactions between ORC and the ORC runtime.

The SimpleExecutorMemoryManager class provides executor-side support for memory
management operations, including finalization and deallocation actions.

This support is being added in advance of the rest of the memory manager
redesign as it will simplify the introduction of an EPC based
RuntimeDyld::MemoryManager (since eh-frame registration/deregistration will be
expressible as actions). The new RuntimeDyld::MemoryManager will in turn allow
us to remove older remote allocators that are blocking the rest of the memory
manager changes.
The file was modifiedllvm/include/llvm/ExecutionEngine/Orc/Shared/OrcRTBridge.h
The file was modifiedllvm/include/llvm/ExecutionEngine/Orc/EPCGenericJITLinkMemoryManager.h
The file was modifiedllvm/lib/ExecutionEngine/Orc/TargetProcess/SimpleRemoteEPCServer.cpp
The file was modifiedllvm/lib/ExecutionEngine/Orc/Shared/OrcRTBridge.cpp
The file was modifiedllvm/lib/ExecutionEngine/Orc/EPCGenericJITLinkMemoryManager.cpp
The file was modifiedllvm/unittests/ExecutionEngine/Orc/EPCGenericJITLinkMemoryManagerTest.cpp
The file was addedllvm/include/llvm/ExecutionEngine/Orc/TargetProcess/SimpleExecutorMemoryManager.h
The file was modifiedllvm/lib/ExecutionEngine/Orc/TargetProcess/CMakeLists.txt
The file was modifiedllvm/tools/llvm-jitlink/llvm-jitlink-executor/llvm-jitlink-executor.cpp
The file was modifiedllvm/lib/ExecutionEngine/Orc/TargetProcess/OrcRTBootstrap.cpp
The file was modifiedllvm/unittests/ExecutionEngine/Orc/CMakeLists.txt
The file was addedllvm/lib/ExecutionEngine/Orc/TargetProcess/SimpleExecutorMemoryManager.cpp
The file was modifiedllvm/include/llvm/ExecutionEngine/Orc/TargetProcess/SimpleRemoteEPCServer.h
The file was modifiedllvm/lib/ExecutionEngine/Orc/SimpleRemoteEPC.cpp
The file was addedllvm/unittests/ExecutionEngine/Orc/SimpleExecutorMemoryManagerTest.cpp
The file was addedllvm/include/llvm/ExecutionEngine/Orc/TargetProcess/ExecutorBootstrapService.h
The file was modifiedllvm/include/llvm/ExecutionEngine/Orc/Shared/TargetProcessControlTypes.h
Commit a9a6cdc1bdc0beeb55129e2b502b7c73101e139a by llvmgnsyncbot
[gn build] Port 78b083dbb725
The file was modifiedllvm/utils/gn/secondary/llvm/unittests/ExecutionEngine/Orc/BUILD.gn
The file was modifiedllvm/utils/gn/secondary/llvm/lib/ExecutionEngine/Orc/TargetProcess/BUILD.gn
Commit 47373f94a431d7fcc78c760ca6ca321f3742b746 by leonardchan
[compiler-rt][test] Add int128 requirement to TestCases/Misc/Linux/static-link.cpp

We hit some undefined symbol errors to 128-bit floating point functions when linking this test.

ld.lld: error: undefined symbol: __multf3
>>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a
>>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a
>>> referenced by strtof128_l.o:(round_and_return) in archive /usr/lib/x86_64-linux-gnu/libc.a
>>> referenced 4 more times
>>> did you mean: __muldf3
>>> defined in: /usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a

Host libc expects these to be defined, and compiler-rt will only define these
for certain platforms (see definition for CRT_LDBL_128BIT). Since we likely
can't do anything about the host libc, we can at least restrict the test to
check that these functions are supported.

Differential Revision: https://reviews.llvm.org/D109709
The file was modifiedcompiler-rt/test/ubsan/TestCases/Misc/Linux/static-link.cpp