[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

Mon Jun 27 02:36:18 PDT 2022

nikic added a comment.

In D103874#3611507 <https://reviews.llvm.org/D103874#3611507>, @aqjune wrote:

> In D103874#3611483 <https://reviews.llvm.org/D103874#3611483>, @nikic wrote:
>
>> Which intrinsic are you working on here? If this is about the mm_undefined intrinsics, why do we need to change those from the current status quo of using a zero value instead of undef?
>
> It is about the `mm256_castpd128_pd256` intrinsic and its friends (clang/test/CodeGen/X86/avx-builtins.c, line 146).
> It was previously using `shufflevector` with undef masks - since the results are poison, an alternative pattern as below is necessary to represent the intrinsic:
>
>   %a1 = freeze <2 x double> poison
>   %res = shufflevector <2 x double> %a0, <2 x double> %a1, <4 x i32> <i32 0, i32 1, i32 2, i32 3>

How sure are we that we cannot simply use `poison` elements here? I checked what the Intel compiler guide has to say on the topic, and it uses the following wording. For "undefined" style intrinsics:

> This intrinsic returns a vector of eight single precision floating point elements. The content of the vector is not specified.

For "cast" style intrinsics:

> The lower 128-bits of the 256-bit resulting vector contains the source vector values; the upper 128-bits of the resulting vector are undefined. This intrinsic does not introduce extra moves to the generated code

It's not really clear what "undefined" is supposed to mean here (and how it differs from "not specified").

Unless we're aware of a specific problems in this area, I think it's okay to start out with just doing the undef -> poison replacement, and possibly backtrack if there are real-world assumptions about the specific meaning of "undefined" in this context.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103874