[mlir] Fix crash in test type converter for 1->N result conversion (#201738)
Use `results.append` instead of `results.assign`, preserving previous
results.
Fixes https://github.com/llvm/llvm-project/issues/201521
[X86] X86FixupInstTuning - fold VPERM2x128 -> VINSERTx128 when shuffling lower xmm half ymm sources (#201618)
VINSERTx128 is never slower than VPERM2x128 and notably quicker on some
targets (btver2, znver1, e-cores, etc.).
Shuffle lowering avoids some VINSERT patterns for AVX targets as it can
affect folding/commutation - but by the time we get to the fixup passes,
these are all done and we can safely convert to VINSERTF128/I128.
There's more variants of the VPERM2 immediate mask that could be folded,
but its incredibly difficult to hit them as its easily commutable.
I hit this while working on #199445.
[SeparateConstOffsetFromGEP] Decompose xor constant operand when possible (#195830)
It may be desirable to fold constants directly into the addressing mode
when computing an address. While lowering GEPs and looking for a
constant to extract among the indexes, take into account constants which
are xor expressions as well. When some bits of the constant operand of
the xor are known-zero in the base operand, then, for those specific
bits (disjoint bits), xor and additions behave alike. Such bits may be
extracted from the xor, and are those that can contribute to the final
GEP offset.
Proofs: https://alive2.llvm.org/ce/z/JtmXsu.
Co-authored-by: Sumanth Gundapaneni <sumanth.gundapaneni at amd.com>
[clangd][modules] Provide correct context to ModulesBuilder::hasRequiredModules() call (#201419)
To make command mangler to use compile command edits from the
configuration, we need to provide the correct context to it.
Without this patch compile command edits declared in .clangd file are
not used during required modules check, which can lead to compile errors
appearing and false negative `ModulesBuilder::hadRequiredModules()`
return result.
This PR addresses problem described here
https://github.com/llvm/llvm-project/pull/200001#issuecomment-4590514342
[NFC][clang] Format pragma comment kind StringSwitch (#201754)
This is a formatting-only change to the pragma comment kind
`StringSwitch`.
A follow-up change needs to add another pragma comment kind to this
block. Applying the formatter as part of that functional change would
also reformat the existing cases, making the functional diff harder to
review.
No functional change intended.
Co-authored-by: Tony Varghese <tony.varghese at ibm.com>
