SuccessChanges

Summary

  1. [ORC-RT] Split Simple-Packed-Serialization code into its own header. (details)
  2. [X86] Check immediate before get it. (details)
  3. llvm-objcopy: fix section size truncation/extension when dumping sections (details)
  4. [runtimes] Fix umbrella component targets (details)
Commit 49f4a58d53c72abee6da3443028fff6bb2d8fe35 by Lang Hames
[ORC-RT] Split Simple-Packed-Serialization code into its own header.

This will simplify integration of this code into LLVM -- The
Simple-Packed-Serialization code can be copied near-verbatim, but
WrapperFunctionResult will require more adaptation.
The file was modifiedcompiler-rt/lib/orc/CMakeLists.txt
The file was modifiedcompiler-rt/lib/orc/common.h
The file was modifiedcompiler-rt/lib/orc/wrapper_function_utils.h
The file was modifiedcompiler-rt/lib/orc/unittests/wrapper_function_utils_test.cpp
The file was addedcompiler-rt/lib/orc/unittests/simple_packed_serialization_test.cpp
The file was addedcompiler-rt/lib/orc/simple_packed_serialization.h
The file was modifiedcompiler-rt/lib/orc/unittests/CMakeLists.txt
Commit 9eb2f723c24523194b833779d20b027bf89a4f55 by yuanke.luo
[X86] Check immediate before get it.

For CMP imm instruction, when the operand 1 is symbol address we should
check if it is immediate first. Here is the example code.
`CMP64mi32 $noreg, 8, killed renamable $rcx, @d, $noreg, @a, implicit-def
$eflags`
Many thanks to Craig, Topper for the test case to reproduce this issue.

Differential Revision: https://reviews.llvm.org/D104037
The file was addedllvm/test/CodeGen/X86/unfoldMemoryOperand.mir
The file was modifiedllvm/lib/Target/X86/X86InstrInfo.cpp
Commit 02c718301b305dff87aa4b204b7b3e6fc647999d by dblaikie
llvm-objcopy: fix section size truncation/extension when dumping sections

Since this only comes up with inputs containing sections at least 4GB
large (I guess I could use a bzero section or something, so the input
file doesn't have to be 4GB, but even then the output file would have to
be 4GB, right?) I've skipped testing this. If there's a nice way to test
this without needing 4GB inputs or output files.

The subtlety here is demonstrated by this code:

struct t { operator uint64_t(); };
static_assert(std::is_same_v<int, decltype(std::declval<bool>() ? 0 : std::declval<t>())>);
static_assert(std::is_same_v<uint64_t, decltype(std::declval<bool>() ? 0 : std::declval<uint64_t>())>);

Because of this difference, the original source code was getting an int
type (truncating the actual size) and then extending it again, resulting
in bogus values (I haven't thought through this hard enough to explain
why the resulting value was 0xffff... - sign extension, possible UB, but
in any case it's the wrong answer - in this particular case I was
looking at that resulted in a size so large that we couldn't open a file
large enough to write to and ended up with a rather vague:

error: 'file_name.o': Invalid argument
The file was modifiedllvm/tools/llvm-objcopy/ELF/Object.cpp
Commit aa93603ff6a4bfd92c64e4f75d60ae9c84d5cdf5 by smeenai
[runtimes] Fix umbrella component targets

When we're building the runtimes for multiple platform targets, we
create umbrella build targets for each distribution component, but those
targets didn't have any dependencies and were just no-ops. Make the
umbrella target depend on the sub-targets for each platform to fix this,
which is consistent with the behavior of the umbrella targets for each
runtime, and also consistent with the behavior when we've only specified
the default target.
The file was modifiedllvm/runtimes/CMakeLists.txt