https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #18 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- I'd understood LLVM's undef as essentially being “unspecified”, or “unspecified bit-pattern” to quote the docs. It doesn't indicate undefined behaviour in the C/C++ sense: Undefined values are useful because they indicate to the compiler that the program is well defined no matter what value is used. And I think that's what we want here. The reason we have TARGET_PREFERRED_ELSE_VALUE is that the vectoriser sometimes doesn't care what values the inactive lanes of the result have. The else value can be anything without affecting the validity of the program. So if we had undef, we wouldn't need the hook. I think the same thing applies to a VEC_PERM_EXPR that only selects from the first vector. We canonicalise that by duplicating the vector input, but IMO an undef second operand would be more accurate. An undef value would also allow us to represent “don't care” indices in a permute index vector, such as -1 in a __builtin_shuffle call. (There were times when I wanted the same thing in the vectoriser too, but I can't remember where.) There again, a separate “care/don't care” mask might be better for VLA. ACLE provides “svundef” functions that have essentially the same semantics as LLVM's undef. So I Think it would be useful to be able to access the semantics outside of these particular IFNs.
