[AArch64][llvm] Fix incorrect diagnostic (index/immediate in simm9)
Improve the error message in the simm9 diagnostics and use the word
'immediate' instead of 'index'. This was noticed when creating the
CFLT instructions for Armv9.8-A, but would have caused a lot of
unrelated churn if merged as part of that change.
Co-authored-by: Martin Wehking <martin.wehking at arm.com>
[AArch64][llvm] Improve diagnostics for invalid operands (#230436)
Return `DiagnosticPredicate` from `isSImm()`, `isImmInRange()`, and
`isUImm12Offset()` so invalid operand types do not produce misleading
immediate range errors, while out-of-range constants retain their
range diagnostics.
Keep the load/store fallback predicate boolean and remove the
CFLT-specific diagnostic workaround. Update affected diagnostic
tests and add prefetch and CFLT regression testcases.
[AArch64] Prefer tst + bcc over lsr + cbz/cbnz (#228005)
Lower (BR_CC eq/ne, (SRL val, imm), 0) to tst + bcc instead of
lsr + cbz/cbnz when the tst and bcc instructions can be fused.
[X86] Custom split `STRICT_CVTPS2PH` with wide types (#231365)
Fixes #230684
A strict `fptrunc` from `<16 x float>` to `<16 x half>` on an AVX2+F16C
target crashed in the type legalizer. `combineFP_ROUND` turns the vector
`STRICT_FP_ROUND` into `X86ISD::STRICT_CVTPS2PH` at whatever width the
IR has, which works for the non-strict node because `LowerOperation` and
`ReplaceNodeResults` know how to split `X86ISD::CVTPS2PH` once v16f32
turns out to be illegal. The strict node never got those entries, so the
legalizer fell through to the default `llvm_unreachable` ("Should not
custom lower this!"), and for `<32 x float>`, where the result type is
illegal too, to the matching one in `ReplaceNodeResults`. Without
assertions this is a plain segfault, also in the 23.1.2 release.
`LowerCVTPS2PH` now handles the strict node as well: it splits the
source, emits two `STRICT_CVTPS2PH` nodes that share the input chain and
the rounding-control immediate, joins their output chains with a
`TokenFactor`, and returns the concatenated value together with the
[4 lines not shown]
[CMake][test] Mark tests as unsupported if the configuring cmake isn't available (#231827)
get-host-triple.test (introduced by #219882) runs the cmake binary that
configured the build (CMAKE_COMMAND). At least for the RISC-V CI
builders this isn't available as they cross-compile in one environment
and run tests in another.
[offload] Add direct-write memcpys to liboffload and implement them on AMDGPU
olMemcpy gets a variant with a flag parameter. The flags are an enum and
DIRECT_WRITE is the first member of it. Specifying DIRECT_WRITE means
that the olMemcpy may issue the copy as a direct H2D write, which means
that it will be unordered with respect to the currently enqueued
operations. It will, however, be completed upon completion of olMemcpy,
so it will not be unordered with respect to operations that get enqueued
afterwards.
The AMDGPU implementation queries is a transfer of the ROCr/HIP
implementation. It more or less boils down to a std::memcpy with fences
around it.
Claude assisted with this patch.
[clang] Handle _Atomic types in hasUniqueObjectRepresentations (#212768)
`__has_unique_object_representations(_Atomic(int))` returns false even
though `_Atomic(int)` has the same object representation as `int`.
Atomic types were never handled: they fail the trivial-copyability check
up front (they aren't scalar types), and `_Atomic T` has been on the
FIXME list at the end of the function since the original implementation.
This is also the root cause of the false positive pinned in the
`bugprone-suspicious-memory-comparison` tests since
[D89651](https://reviews.llvm.org/D89651).
Handle `AtomicType` explicitly: `_Atomic(T)` has unique object
representations iff `T` does and the atomic's size wasn't rounded up to
a power of two (see `getTypeInfo`), since the rounding bytes are
padding. The branch goes before the trivial-copyability check, which
atomics always fail; triviality is judged on the value type instead.
Adds trait asserts to `type-traits.cpp` and flips the tidy FIXME test to
expect no diagnostic. This is groundwork for a follow-up PR adding a
Sema warning for `memcmp` on types without unique object
representations, so the known false positive needed fixing first.
AMDGPU: Don't check liveness in AMDGPUAttributor
AAIsDead is not in the set of AMDGPUAttributor enabled AAs, so the
liveness checks of the Attributor never find anything dead. They still
looked up AAIsDead for each visited instruction and use, for every
update.
The output IR is unchanged on the modules below. Instructions spent in
amdgpu-attributor (opt, parse cost subtracted, median of 3 runs):
rocPRIM test_device_scan, gfx942: 1963M -> 1442M (-26.5%)
Blender Cycles HIP kernel, gfx1100: 636M -> 497M (-21.9%)
rocPRIM 16 tests, full LTO, closed world: 7415M -> 5152M (-30.5%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
