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