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

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 20 Jul 2023, kito at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> 
> --- Comment #4 from Kito Cheng <kito at gcc dot gnu.org> ---
> > OK, so TA is either merge or all-ones.
> 
> Yes, your understand is correct, just few more detail is that can be mixing
> with either merge or all-ones.
> 
> e.g.
> 
> An 4 x i32 vector with mask 1 0 1 0
> 
> Op  =  | a | b | c | d |
> Mask = | 1 | 0 | 1 | 0 |
> 
> the result could be:
> | a | b | c | d |
> | a | all-1 | c | d |
> | a | all-1 | c | all-1 |
> | a | all-1 | c | d |
> 
> 
> > Not sure how you can use MA at the moment since you specify an existing operand in your target hook.  As far as
> > I can see there's no value the target hook can provide that matches any
> of the implementation semantics?
> 
> That's the key point - we don't know how to return an undefined value there, we
> have intrinsic can generate undefined value, but it seems impossible to
> generate that within the hook.

Well, neither *A nor *U can be specified currently.  As said for 'merge'
we would need another operand.  And since 'unspecified' is either merge
or all-ones we can't express that either.  It's not really 'undefined'
either.

Note this also means the proposal to define a .MASK_LOAD as zeroing
masked elements is not going to work for RISC-V, instead we'd need
an explicit 'else' value there as well.

In fact we could follow .MASK_LOAD for .COND_* and simply omit
the 'else' operand for the case of 'unspecified', no?  GIMPLE would
be fine omitting it, not sure whether there's precedent for
optabs with optional operands?