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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
