[X86] Don't shrink VEX3 to VEX2 on a symbolic compare predicate (#213172)
`llvm-mc` asserts on a VCMP predicate given as a symbol:
```asm
vcmpps $f0, %xmm0, %xmm1, %xmm2
```
```
Assertion failed: isImm() && "This is not an immediate", MCInst.h:85
```
`optimizeInstFromVEX3ToVEX2` reads the predicate with `getImm()` to
decide whether the operands commute. A symbolic predicate is not known
until link time, so that decision cannot be made here. Decline the
shrink instead.
Unlike the sibling FPCLASS issues (#185364, #185365) this one is on the
encoding path and asserts under `--filetype=obj` too, so a release build
[6 lines not shown]
[RISCV] Fix assertion in combineBinOpOfExtractToReduceTree on type mismatch (#202201)
combineBinOpOfExtractToReduceTree asserts that the extract source
vector's element type equals the binop's value type
(SrcVecVT.getVectorElementType() == VT). This invariant does not hold
for all valid inputs.
A <1 x i1> binary operation under -mattr=+zve32x reaches this point with
the source vector element type differing from VT, which trips the
assertion in an assertions-enabled build and silently proceeds on a
false assumption otherwise.
Convert the assertion into an early return, so the combine declines when
its precondition is not met. This matches the existing bail-out style in
the same function (the isScalableVector and getScalarSizeInBits() >
getELen() checks immediately following). The change only ever skips the
fold; it never alters correct output.
Generative AI was used for the test case. The fix
[3 lines not shown]
[LAA][NFC] Refactor deref no-wrap check; expose broken reverse-loop bounds (#211960)
Split evaluatePtrAddRecAtMaxBTCWillNotWrap into two stages: compute
MaxOffset based on the step direction, then apply the shared
MaxOffset <= DerefBytes check.
Rename intermediate values to reflect what they actually represent.
This restructuring makes two long-standing off-by-EltSize issues in
the negative-step path explicit:
* The lower-bound check is over-conservative by EltSize.
* The upper-bound check under-counts by EltSize.
[AMDGPU] gfx1250 co-execution scheduler
Snapshot of the gfx1250 co-execution scheduling work, squashed into a
single commit on top of llvm/llvm-project e2a39f504fee.
Includes the co-execution window model (AMDGPUCoExecInfo.h), the
CoExecSchedStrategy window-slot-demand machinery, pre-RA and post-RA
co-execution hazard tracking in GCNHazardRecognizer, the gfx1250 static
simulator (AMDGPUStaticSimulator), expert-mode waitcnt work in
SIInsertWaitcnts, and the supporting lit and MIR tests.
Authored by, in no particular order:
Austin Kerbow, Jeffrey Byrnes, Alexey Sachkov, Lucas Ramirez,
Volkan Keles, Hideki Saito, Jay Foad, Brendon Cahoon,
Ilia Cherniavskii, Alexander Weinrauch, Vigneshwar, proaditya,
mssefat, Lei Zhang
[AMDGPU] gfx1250 co-execution scheduler
Snapshot of the gfx1250 co-execution scheduling work, squashed into a
single commit on top of llvm/llvm-project 7570d2daec56.
Includes the co-execution window model (AMDGPUCoExecInfo.h), the
CoExecSchedStrategy window-slot-demand machinery, pre-RA and post-RA
co-execution hazard tracking in GCNHazardRecognizer, the gfx1250 static
simulator (AMDGPUStaticSimulator), expert-mode waitcnt work in
SIInsertWaitcnts, and the supporting lit and MIR tests.
Authored by, in no particular order:
Austin Kerbow, Jeffrey Byrnes, Alexey Sachkov, Lucas Ramirez,
Volkan Keles, Hideki Saito, Jay Foad, Brendon Cahoon,
Ilia Cherniavskii, Alexander Weinrauch, Vigneshwar, proaditya,
mssefat, Lei Zhang
clang: Emit "long-double-type" module flag generically
Move emission of the "long-double-type" module flag out of PowerPC
and into generic code, so it describes the long double format for all
targets.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[NFC][AMDGPU] Add tests for an fmul split from its fadd/fsub user (#213303)
Record the current behaviour over the types and subtargets where the
fusion rules differ, f32, f16, bf16, f64, v2f32 and v2f16, with
denormals both enabled and flushed, with and without the contract flags,
and under -fp-contract=fast.
Contributes to https://github.com/llvm/llvm-project/issues/211092
[ConstraintElim] Decompose xor %a, -1 as -1 - %a in the signed system. (#213476)
InstCombine canonicalizes sub nsw i8 -1, %a -> xor i8 %a, -1. Decompose
the XOR as `sub nsw -1, %a` in the signed system
Alive2 Proof: https://alive2.llvm.org/ce/z/f_YVjH
This triggers quite rarely in C/C++ workloads (no end-to-end changes in
https://github.com/dtcxzyw/llvm-opt-benchmark-nightly/pull/840), found
one instance in Blender. One simple end-to-end C example is
https://clang.godbolt.org/z/G343shYje
This is part of an effort to improve ConstraintElimination support for
IR generated by the Swift compiler, where such patterns are more common
due to a number of signed runtime checks.
PR: https://github.com/llvm/llvm-project/pull/213476
[ELF] Emit synthetic local in symbol table for non-preemptible IFUNC
Currently we create an internal alias of the original symbol and then
rewrite the latter to point to the IPLT entry, which means we lose
symbol table information for the actual resolver. In practice compilers
also emit a normal function symbol for the resolver due to how IFUNCs
are represented in GNU C so that at least shows up, but we shouldn't be
relying on it. By emitting a synthetic local we can keep having a symbol
for the resolver whilst still redirecting references to the IPLT entry.
[NFC][ELF] Remove Symbol's unused copy constructor
Now that we are no longer copying symbols via the copy constructor we
can remove it. Given we track symbol pointers in various data structures
it can be dangerous to have multiple objects for the same symbol that
would risk being viewed inconsistently, or even moved and the original
lost, though no such cases exist upstream that I'm aware of.
Copying a symbol entirely is also a weird thing to do, and can be
inefficient, so when copies are being made it's best to be explicit
about the members to copy. This also makes it clearer to understand what
members are relevant, rather than implicitly copying all the members,
most of which aren't relevant in practice.
Whilst the copy/move constructors/assignment operators are currently
implicitly deleted due to the atomic flags member, explicitly delete
them all so they remain deleted in case that ever changes.
[NFC][ELF] Create fresh alias in handleNonPreemptibleIfunc
We don't need to copy the full symbol here, we just want an internal
alias to use for the IPLT and IGOTPLT entries and IRELATIVE relocation's
addend.
[NFC][ELF] Only create alias in handleNonPreemptibleIfunc if needed
In the no direct relocations case, the original IFUNC symbol keeps its
value, and so there's no need to create a separate alias; it's only
needed when the original symbol is being redirected to the IPLT as a
normal function symbol.
This change also shifts the isInIplt assignment to be explicit and
mirror the allocateAux/pltIdx uses, rather than relying on makeDefined
copying it, and to be clear that this is in fact deliberately and
consistently being copied like them.
[NFC][ELF] Avoid need to copy Symbol in replaceWithDefined (#210612)
Firstly, by overwriting the symbol, it will have its existing flags, so
there is no need to copy them back; all we need to do is mask out the
other bits on the existing symbol.
Secondly, copying the whole symbol just to preserve the symbol version
that gets cleared by Defined::overwrite is a waste; just copy the single
member to reinstate it.
clang/AMDGPU: Fix confused image builtin availability tests
These tests appear to have been copy paste from other image error
tests, which were checking for invalid argument validation. The point
of these tests were to reject image builtins on unsupported targets,
and not just gfx942. Rename the tests, and fix the invalid argument usage.
Each builtin should be used in a valid way.
Co-authored-by: Claude (Claude-Opus-4.8)
[flang] Remove unused includes in MIFCommon.cpp to fix GCC debug-build link errors (#213508)
An undefined symbol error when building Flang in debug mode. This PR fix
this by remove unused include file. Here is a brief error log:
`/usr/bin/ld:lib/libFIRBuilder.a(MIFCommon.cpp.o): in function
Fortran::evaluate::FunctionRef<Fortran::evaluate::Type<(Fortran::common::TypeCategory)4,
1> >::~FunctionRef()':`.
