[PATCH] D70641: [LangRef] make per-element poison behavior explicit

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 25 06:48:41 PST 2019


spatel added a comment.

In D70641#1758212 <https://reviews.llvm.org/D70641#1758212>, @nlopes wrote:

> The first bit looks ok to me, thanks!
>
> The semantics for shufflevector doesn't. TL;DR: instructions can't detect undef and have some special behavior dedicated to undef.
>  (I said before this semantics for shufflevector could be ok, but I was wrong, sorry)
>
> Longer version:
>  undef can be replaced with any number, including in the shufflevector mask. An undef mask may be replaced with an out-of-bounds index, or point to any element in either of the input elements. If one of those input elements is poison, then the result of shufflevector with undef mask may be poison.
> Example:
>  %v = shufflevector <2 x float> %x, <2 x float> undef, <2 x i32> <i32 undef, i32 0>
>  ->
>  %v = shufflevector <2 x float> %x, <2 x float> undef, <2 x i32> <i32 1, i32 0>
>  ->
>  %v = <%x[1], %x[0]>
>
> If %x[1] is poison, we get: %v = <poison, %x[0]>
>
> Alternative optimization for the same instruction:
>  %v = shufflevector <2 x float> %x, <2 x float> undef, <2 x i32> <i32 undef, i32 0>
>  ->
>  %v = shufflevector <2 x float> %x, <2 x float> undef, <2 x i32> <i32 2, i32 0>
>  ->
>  %v = <undef, %x[0]>
>
> The point is that if mask is undef, we can't promise to give undef.
>  AFAICT, the only way to fix this is to say that if the mask is out-of-bounds, we yield poison. That's correct because there's nothing worse than poison.


Can you raise this on llvm-dev (if it wasn't already)? I'll see if I can isolate the transforms that are currently in conflict and the potential optimization fallout.


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

https://reviews.llvm.org/D70641





More information about the llvm-commits mailing list