[PATCH] D149548: [IR] Update to use new shufflevector semantics

Nuno Lopes via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jun 12 05:51:42 PDT 2023


nlopes added a comment.

In D149548#4413598 <https://reviews.llvm.org/D149548#4413598>, @uweigand wrote:

> So the semantics of the `vec_promote(a, b)` intrinsic is defined as:
>
>> Returns a vector with a in element position b. The result is a vector with a in element position b. [...] The other elements of the vector are undefined.
>
> This is currently implemented by using `insertvector` to place `a` at position `b` into a source vector that is `undef`.   The effect should be that when using element `b` of that vector, we are guaranteed to get `a`, while using any other element is undefined behavior (just like accessing an uninitialized variable).
>
> To be honest, I'm not sure how exactly the LLVM IR semantics changes here when using a `poison` source vector instead of `undef`.  I seem to recall that `poison` propagates over operations - is it true that the result of `insertvector` on a `poison` vector is itself `poison`?  If so, then this change would break semantics.   However, if the result is a vector with `a` in element `b`, and `poison` only in the other elements, then I guess this would still preserve the expected semantics.

If a vector is fully initialized with `insertvector` (i.e., one operation per index), then the value of the base vector is irrelevant. It can be poison.
Poison in vectors is element-wise. <poison, 42> doesn't propagate to <poison, poison>.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149548/new/

https://reviews.llvm.org/D149548



More information about the cfe-commits mailing list