[llvm] [WebAssembly] Fold constant `i8x16.swizzle` and `i8x16.relaxed.swizzle` to `shufflevector` (PR #169110)

via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 21 23:56:53 PST 2025


valadaptive wrote:

Looking at the LangRef, I noticed:

> A ‘poison’ value (described in the next section) should be used instead of ‘undef’ whenever possible. **Poison values are stronger than undef,** and enable more optimizations.

and

> **It is correct to replace a poison value with an [undef value](https://llvm.org/docs/LangRef.html#undefvalues)** or any value of the type.

The swizzle optimization implemented here checks `isa<UndefValue>` for each element, which seems to also work for `poison`, and sets the corresponding shuffle index to -1 if so. I *believe* out-of-bounds swizzle elements become `poison`. A couple questions then:

- Is `isa<UndefValue>` the correct thing to check? There are a lot more uses of  `isa<UndefValue>` than  `isa<PoisonValue>` in the codebase, and it's what the original x86 optimization uses.

- Given that the LangRef says that poison is "stronger than undef", and that it is correct to replace a poison value with undef but not vice versa, is it correct to optimize an undef mask element in the input to a poison element in the output? The LangRef says:
  > A poison element in the mask vector specifies that the resulting element is poison. **For backwards-compatibility reasons, LLVM temporarily also accepts undef mask elements, which will be interpreted the same way as poison elements.**

  But it's unclear if this means "an undef element specifies that the resulting element is undef", or "an undef element specifies that the resulting element is poison".

  Again, this is the same behavior as the existing x86 permute optimization.

https://github.com/llvm/llvm-project/pull/169110


More information about the llvm-commits mailing list