[AMDGPU][NFC] Add gfx13 MC tests for v_mov_b16 and v_swap_b16 (#220863)
Both instructions were already supported on gfx13 but had limited MC
tests coverage.
[BOLT][test] Allow uninstantiated tests when no matching targets are enabled (#217604)
When neither X86 nor AArch64 is enabled, e.g. when only enabling the
RISCV target, `check-bolt-unit` triggers GTest's uninstantiated suite
errors on the following cases:
```plain-text
BOLT-Unit :: Core/./CoreTests/GoogleTestVerification/UninstantiatedParameterizedTestSuite<BinaryContextTester>
BOLT-Unit :: Core/./CoreTests/GoogleTestVerification/UninstantiatedParameterizedTestSuite<MCPlusBuilderTester>
BOLT-Unit :: Core/./CoreTests/GoogleTestVerification/UninstantiatedParameterizedTestSuite<MemoryMapsTester>
BOLT-Unit :: Profile/./ProfileTests/GoogleTestVerification/UninstantiatedParameterizedTestSuite<PerfScriptTestHelper>
```
... which looks like the following:
```plain-text
******************** 20:28 [95/2055]
FAIL: BOLT-Unit :: Core/./CoreTests/6/9 (7 of 12)
******************** TEST 'BOLT-Unit :: Core/./CoreTests/6/9' FAILED ********************
[35 lines not shown]
[CIR] Convert i1 intrinsic results for bool-returning builtins (#220576)
A target builtin with no special case is emitted through the generic
intrinsic path, which returns the intrinsic's own result type. For a
builtin declared to return bool that type is i1, which CIR models as
!cir.int<u, 1> rather than !cir.bool. cir.if accepts only !cir.bool, so
CIR builtin handling needs to convert i1 results to !cir.bool when used
in this context.
This is verified using __builtin_amdgcn_is_shared.
---------
Signed-off-by: Steffen Holst Larsen <sholstla at amd.com>
[CodeGen] Increase CCState::UsedRegs inline capacity (NFC) (#221259)
CCState::UsedRegs holds one bit per target register. Its inline capacity
of 16 x 32-bit words only covers 512 registers, causing heap allocations
for AArch64 (895), RISCV (645), and PowerPC (612). Increase it to 32,
covering up to 1024 registers and keeping the storage inline for these
targets.
Assisted-by: codex
[CIR][OpenCL][NFC] Add language address-space lowering coverage (#219900)
Expand coverage for lowering OpenCL language address spaces through
target-specific CIR and LLVM IR, including comparison with classic
CodeGen.
Assisted-by: Codex / GPT-5.6 Sol
[orc-rt] Compose Bedrock from object libraries (#221650)
Add orc-rt-bedrock-objects, and rename orc-rt-support to
orc-rt-support-objects, leaving orc-rt-bedrock as a shipped library with
no sources of its own that is composed from both. The -objects suffix
marks targets that produce no artifact.
The unit tests now link the object libraries directly rather than the
shipped library. This will allow them to continue working when Bedrock
becomes buildable as a dylib with no C++ API exported.
[SLP][modularisation][NFC] Move isFixedVectorShuffle to SLPUtils (#221639)
Move the BoUpSLP-independent shuffle helper out of SLPVectorizer.cpp
into SLPVectorizer/SLPUtils.{h,cpp}:
isFixedVectorShuffle
It sits with the existing shuffle/mask helpers. Behavior is unchanged.
Part of the SLPVectorizer.cpp modularization effort:
https://discourse.llvm.org/t/modularizing-slpvectorizer-cpp/90922
[Mips] Use ELF binding when expanding PIC la (#217566)
A symbol already assigned to a section is not necessarily local. Use ELF
symbol binding when expanding PIC `la`, retaining the existing
section-based fallback for non-ELF targets, so defined default-visible
globals use the correct global GOT form.
Adds `llvm/test/MC/Mips/macro-la-pic-defined-global.s` covering global,
local, and `$25` call-register expansions.
Fixes #217371
(cherry picked from commit eac7a734625083fc78164f1b7d67a74cb5ab334f)
[flang-rt] Fix runtime/environment.cpp compilation on FreeBSD (#219705)
`runtime/environment.cpp` doesn't compile on FreeBSD:
```
runtime/environment.cpp:115:47: error: use of undeclared identifier 'RTLD_DEFAULT'
115 | auto envpp{reinterpret_cast<char ***>(dlsym(RTLD_DEFAULT, "environ"))};
| ^~~~~~~~~~~~
```
`<dlfcn.h>` needs to be included.
Tested on `x86_64-pc-freebsd15.1` and `x86_64-pc-linux-gnu`.
(cherry picked from commit 20102748a3548a1006e32056868cb3df8ce83565)
[MIPS] Fix GP-relative selection after select/add combine (#215414)
## Summary
- Rewrite `$gp + select(...)` before MIPS instruction selection when a
select
arm contains a GP-relative relocation.
- Keep each `MipsISD::GPRel` attached to a selectable add operation.
- Add MIPS32 regression coverage and update the resulting MIPS64 checks.
## Background
The generic DAG combiner can transform:
select C, (add $gp, %gp_rel(A)), (add $gp, %gp_rel(B))
into:
add $gp, (select C, %gp_rel(A), %gp_rel(B))
[34 lines not shown]
[Mips] Select GPR register class based on requested type size (#220012)
In MipsTargetLowering::getRegisterByName(), the register class was
previously selected solely based on Subtarget.isGP64bit(), ignoring the
requested value type size (VT).
When compiling for a 64-bit MIPS CPU with the 32-bit o32 ABI (such as
-mcpu=mips3 -target-abi=o32), Subtarget.isGP64bit() is true even though
32-bit registers are expected. Reading a 32-bit named register like $gp
(e.g., via llvm.read_register.i32) returned a 64-bit register ($gp_64).
This resulted in a cross-register-class copy from GPR64 to GPR32 that
MipsSEInstrInfo::copyPhysReg() could not lower. In builds without
assertions, this constructed an invalid TargetOpcode::PHI (opcode 0)
instruction and caused a crash in MipsMCCodeEmitter during object file
emission.
Inspect VT.getSizeInBits() in getRegisterByName() to select
GPR32RegClassID for 32-bit types and GPR64RegClassID for 64-bit types
when supported by the subtarget, reporting an error for invalid types.
[5 lines not shown]
[clang-format] Keep empty Java interface/record body on one line (#219910)
`AllowShortRecordOnASingleLine` (introduced for C++ records) made
`LineJoiner::tryFitMultipleLinesInOne` route Java `TT_RecordLBrace`
lines to `tryMergeRecord`, which only handles C++ class/struct/union
records. Empty Java `interface` and `record` bodies were therefore no
longer merged onto a single line, regressing the behavior that
`BraceWrapping.SplitEmptyRecord: false` previously provided.
Handle Java records separately and restore the pre-existing
`SplitEmptyRecord`-based merge.
Fixes #219711
(cherry picked from commit 6d390ea43be046d62bc880524ffc4734a21307a7)
[libc] Disable float16 on 32-bit x86 without SSE2 (#219675)
Fixes #219668
Building llvm 23.1.0 (and current main) for 32-bit x86 without SSE2
fails since APFloat.cpp started including libc's shared/math.h. All the
errors come from the float16 headers:
```
libc/src/__support/FPUtil/BasicOperations.h:63:67: error: SSE register return with SSE2 disabled
libc/src/__support/math/acosf16.h:73:14: error: invalid conversion from type '_Float16' without option '-msse2'
```
The float16 detection in float16-macros.h checks __FLT16_MANT_DIG__.
Since GCC 14 that macro is defined on ia32 even without SSE2, where
_Float16 is storage-only and any arithmetic or returning by value is an
error.
The GCC 14 release notes say to check __SSE2__ for arithmetic support
instead: https://gcc.gnu.org/gcc-14/changes.html
[12 lines not shown]
[SelectionDAG] Avoid irregular INSERT_SUBVECTOR when widening CTTZ_ELTS (#218019)
Fixes #217985
Non-poison `CTTZ_ELTS` pads widened operands with active lanes using
`INSERT_SUBVECTOR`. For irregular fixed-length vectors whose
widened type subsequently requires splitting, this can reach the
`SplitVecRes_INSERT_SUBVECTOR` stack-spill fallback.
That fallback calls `getVectorSubVecPointer`, which requires
byte-addressable elements.
Use `VECTOR_SHUFFLE` for this specific widening case. Original lanes are
selected from the normally widened source, while padding lanes are
selected from an all-ones vector. This avoids the irregular
`INSERT_SUBVECTOR` and prevents poison/undef widened padding from being
observed.
Other widening cases retain their existing behavior.
[7 lines not shown]
[SPIRV] Fix inconsistent operand order for counter resource intrinsic
The `llvm.spv.resource.handlefrombinding` intrinsic stores its binding operands in the order (DescriptorSet, BindingNo, ...). The `llvm.spv.resource.counterhandlefrombinding` intrinsic should use the same order.
The `llvm.spv.resource.counterhandlefrombinding` intrinsic is currently emitted only by the `SPIRVLegalizeImplicitBinding` pass. The pass previously interpreted and rebuilt its operands in the wrong order, and the instruction selector repeated the same inversion when emitting decorations.
This change makes the operand order consistent with `llvm.spv.resource.handlefrombinding`.
[clang][Sema][CUDA,SPIRV] Instantiating function templates duplicates GPU attrs (#218582)
A number of GPU related attributes were incorrectly falling back to the
generic attribute instatiation logic which resulted in duplicating the
attributes. The duplicates were also not correctly instantiated.
This also exposed a failure to prevent duplicate addition in
handleGlobalAttr as well.
[flang] Enable wrap-unstructured-constructs-in-execute-region by default
More extensive testing since the flag was introduced, with the
regressions it uncovered now fixed.
[RISCV] Andes: model fast unaligned accesses for the 45-series (#221166)
The 45-series cores support unaligned scalar accesses. Add
FeatureUnalignedScalarMem to each 45-series processor (andes-n45,
andes-nx45, andes-a45, andes-ax45 and andes-ax45mpv), so that it is
selected by -mcpu rather than -mtune. Other processors declare it this
way too. The feature is somewhat architectural: -mtune is only supposed
to affect performance, but reaching it through tune features lets -mtune
introduce unaligned accesses that crash on a CPU which does not support
them.
Cover this in memcpy.ll using -mcpu=andes-a45/-mcpu=andes-ax45. The new
RUN lines pass -mtune=rocket so that the 45-series scheduling model does
not reorder the output, letting them reuse the existing check lines.
Co-authored-by: Claude Opus 5 (1M context) <noreply at anthropic.com>
[SLP][modularisation][NFC] Move getNumberOfParts, isAllowedNonPowerOf2VF (#220827)
Move the following BoUpSLP-independent type/width helpers out of
SLPVectorizer.cpp into SLPVectorizer/SLPTypeUtils.{h,cpp}:
getNumberOfParts
isAllowedNonPowerOf2VF
Both read a file-local cl::opt (SLPReVec and VectorizeNonPowerOf2
respectively). The options stay static in SLPVectorizer.cpp; the moved
helpers take their values as explicit bool parameters. Behavior is
unchanged.
Part of the SLPVectorizer.cpp modularization effort:
https://discourse.llvm.org/t/modularizing-slpvectorizer-cpp/90922
[InterleavedLoadCombine] Index candidates to avoid quadratic matching (#213053)
Matching scanned every candidate against every other candidate, which
got very slow on functions with many interleaved loads. Index by address
offset and look up neighbors instead.
llc's Compile-time drops from 212s to ~2s on a Grace machine for the
test case in the issue.
[ Compile-time remains flat
](https://llvm-compile-time-tracker.com/?config=Overview&stat=instructions%3Au&remote=madhur13490)
Fixes #162299.
Assisted by Cursor.
[libc++] Implement LWG4072: std::optional comparisons: constrain harder (#209968)
Resolves #118345.
Previously, the heterogeneous comparison operators (`==`, `!=`, `<`,
`<=`, `>`, `>=`) for arguments `T` and `U` don't check that `T` or `U`
are not a `std::optional` themselves. This allowed the operators to
cause ambiguous overload resolution instead of falling back to
`optional`'s own operators, which possibly caused hard error when there
should not be a matched overload.
This patch implements the resolution by adding
`!__is_std_optional_v<_Up>` (and the `_Tp` equivalent for the reversed)
to the constraints in all twelve involved operators.
As required by the LLVM Project's AI use policy:
- The fix and test processes were revised and verified with AI
assistance.
Revert "[ELF] Omit zero-range FDEs from .eh_frame_hdr" (#221624)
Reverts llvm/llvm-project#220492
This causes the RISC-V buildbots to fail in the exception handling
tests, see https://lab.llvm.org/buildbot/#/builders/210/builds/12623 for
the gauntlet build logs
Apologies this revert is coming in so late, there is a proposed fix at
https://github.com/llvm/llvm-project/pull/221342 but it looks like it
might require additional rounds of review so reverting to get the
buildbots back to green for now
cc @MaskRay @Prabhuk
