[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]
