[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rsandifo@gcc.gnu.org from comment #18)
> 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.

Sure, I can kind of see the usefulness elsewhere.  Just for this particular
issue it doesn't seem necessary to sit down and design this when we can
represent it like we do for MASK_LOAD (omit the 'else' value).  As noted
above we have the use-case of a not undefined 'else' value.  But I agree,
in theory we could drop the target hook and omit the 'else' value when
we don't need any particular one.

So what I want to point out is that we're fine without for MASK_LOAD so
we should be fine without elsewhere as well.

In other context we discussed specifying zero for MASK_LOAD masked elements
so we can for example CSE better.  CSE with UNDEF might be possible as well,
but I'm not sure what LLVM's undef would allow and whether it's defined
rigidly enough.