[SystemZ][z/OS] Fix "relative immediate relocation section mismatch" (#222437)
Constants should go inside the text section, but this is not explicitly
coded. In the test case, the EH table is generated into a PR section.
Then the constant pool of function `fn_with_const_pool()` is emitted,
which goes into the PR section of the EH table instead of the code
section. When the constant is later referenced in the code, the relative
offset cannot be calculated because different sections are involved.
The fix is to explicitly return the text section for constants.
[llvm-ar][GOFF] Implement symbol attributes for GOFF archives (#214528)
z/OS archive symbol table entries contain a 32-bit attribute word
alongside each member offset.
The low three bits encode:
```
bit 2 (0x4): 64-bit addressing (AMODE 64)
bit 1 (0x2): XPLink calling convention
bit 0 (0x1): Writable Static Area (WSA)
```
Previously in e2c8fa0, llvm-ar wrote zero for these attributes. This
patch reads them from GOFF ESD
records and stores them in a SymbolAttrs vector parallel to the existing
Symbols vector in MemberData
to emit the correct word per symbol.
These attributes are tested using `llvm-nm --print-armap` implemented in
#214527 within the LIT test.
CodeGen: Remove TargetOptions::EABIVersion
The field's only effect was gating the __aeabi_mem*[4|8] libcalls via the
IsEABI4/IsEABI5 predicates. That distinction is derivable from the triple's
environment, so replace the two predicates with a single
triple-derived IsEABIVersion and delete the field.
The clang -meabi option and clang::TargetOptions::EABIVersion are
retained (now codegen-inert); the llc/opt -meabi flag is removed. -meabi
now only takes effect on triples with a bare-EABI/GNU environment pair
(arm-none-eabi <-> gnueabi), which is the only case with a triple
representation.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
clang/ARM: Derive -pg mcount name from the triple environment
For a glibc/gnueabi ARM and AArch64 targets, GCC's -pg instrumentation
always calls __gnu_mcount_nc (with the caller pushing LR, per the "nc"
no-LR-clobber ABI). clang only produced this when -meabi=gnu was passed
explicitly; a separate gnueabi triple wrongly called plain "mcount".
On ARM, glibc's EABI profiling entry point is __gnu_mcount_nc
(sysdeps/arm/arm-mcount.S, exported since GLIBC_2.8). It does provide plain
mcount/_mcount, but only as a legacy APCS compat alias (__mcount_arm_compat,
gated on GCC_COMPAT(4,3)/SHLIB_COMPAT) that reads an APCS frame-pointer
record rather than following the EABI push-LR convention. Calling it from
EABI -pg code is thus an ABI mismatch, not the intended entry point.
Derive the GNU-vs-plain mcount name from the triple environment in addition
to the explicit -meabi=gnu, so a gnueabi target gets the correct __gnu_mcount_nc
call by default, matching GCC:
push {lr}
[5 lines not shown]
[OpenMP] Avoid use of ConstantExpr::getSizeOf() (#222662)
Support for this will be dropped as part of the ptradd migration.
Replace with a constant size.
While I'm touching the code anyway, I also simplified the size
calculation a bit. It's computing both the size in bytes and in
elements. Avoid doing an unnecessary division followed by multiply for
the size in bytes.
[SystemZ][z/OS] Correctly align the constant pool and the PPA1 (#222128)
Both should be half-word aligned. However, testing revealed that both
can end up on odd addresses, which leads to relocation errors. Fix is to
change the alignment.
[Hexagon] Lower vreduce(min|max)((imum)?) (#211898)
Add custom lowering for VECREDUCE_FMIN/FMAX/FMINIMUM/FMAXIMUM on HVX
float vector types. The target-independent default expansion reduces
these pairwise using the hardware min/max instruction directly, which
does not implement IEEE-754 NaN-propagation semantics: a NaN in the
input can silently corrupt the reduction result, and an all-NaN input
produces a non-NaN value instead of NaN.
The custom lowering strips NaN elements to the appropriate neutral value
(+/-Inf) before the pairwise tree reduction so a NaN can't corrupt other
lanes, then fixes up the scalar result to NaN if every input element was
NaN.
FMINNUM/FMAXNUM on HVX vector types get the same treatment: NaN operands
are replaced with the neutral value before delegating to the hardware
min/max, with a fixup to restore NaN when both operands were NaN (per
llvm.minnum/maxnum semantics).
Co-authored-by: Kaushik Kulkarni <kauskulk at qti.qualcomm.com>
[mlir] Reuse the MLIRIR PCH through dependencies (NFC)
Track whether an MLIR library's link closure reaches MLIRIR and reuse the
MLIRIR PCH for those libraries. Preserve higher-priority local PCHs and add an
explicit opt-out for targets whose sources are incompatible with reuse.
Relative to the core and LLVM dialect PCH parent, clean Release builds of LLVM
and MLIR with Ninja -j16 pinned to CPUs 16-31 improved as follows:
wall: 398.79s -> 386.47s (-3.09%)
user: 5789.14s -> 5624.02s (-2.85%)
system: 455.05s -> 438.45s (-3.65%)
Assisted-by: Codex
[mlir][LLVM] Reuse a PCH for MLIRLLVMDialect (NFC)
Build a private precompiled header from the LLVM dialect and LLVM IR headers
and use it for MLIRLLVMDialect. Build dialect libraries before conversions so
the PCH is available early and repeated parsing is avoided.
Relative to the MLIRIR PCH parent, clean Release builds of LLVM and MLIR with
Ninja -j16 pinned to CPUs 16-31 improved as follows:
wall: 420.41s -> 398.79s (-5.14%)
user: 6125.97s -> 5789.14s (-5.50%)
system: 481.88s -> 455.05s (-5.57%)
Assisted-by: Codex
[mlir] Reuse a precompiled header for MLIRIR (NFC) (#222576)
Build a private precompiled header from the common MLIR IR headers and
use it for MLIRIR. Build Support and IR first so the PCH is available
early, and qualify the LLVM LSP Location name that the broader header
surface exposes.
On current main, clean Release builds of LLVM and MLIR with `ninja -j16`
improved as follows:
```
wall: 535.99s -> 420.41s (-21.56%)
user: 7550.29s -> 6125.97s (-18.86%)
system: 569.85s -> 481.88s (-15.44%)
```
Assisted-by: Codex
[Passes] Add DisableSimplifyLibCalls flag to runCodeGenPipeline (#222430)
This enables this abstraction to be a drop-in replacement for rustc
after some minor refactoring.
[lldb] Move most PDB shell tests to NativePDB (#222370)
I plan to remove the DIA PDB plugin before the 24 release - we switched
the default to the native one in 22. To avoid losing test coverage in
the process, this moves the SymbolFile/PDB tests to
SymbolFile/NativePDB. They were already running with both plugins. In
some cases, we set `env LLDB_USE_NATIVE_PDB_READER=1`, which I flipped.
The remaining shell tests are:
- `func-symbols.test`: Has a duplicate in NativePDB with different
checks, because the two plugins don't create identical types (see
comment in test)
- `udt-layout.test`: Also has a duplicate with different checks, because
the two plugins show the base classes in a different order.
Other than that, there's also a [unittest for
PDB](https://github.com/llvm/llvm-project/blob/2de38b4861ed4a7be7ddd42fc803e91d1fe81b14/lldb/unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp).
I'm not sure what we should do about it. Looking over the tests there,
most of these are already covered by the shell tests.
