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

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rguent...@suse.de from comment #5)
> 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?

For RVV auto-vectorization, we define COND_LEN_* has else value in the
arguments. But the else value is not always the real value we need to
care about, this is the code from vectorizable_operation:

          if (reduc_idx >= 0)
            {
              /* Perform the operation on active elements only and take
                 inactive elements from the reduction chain input.  */
              gcc_assert (!vop2);
              vops.quick_push (reduc_idx == 1 ? vop1 : vop0);
            }
          else
            {
              auto else_value = targetm.preferred_else_value
                (cond_fn, vectype, vops.length () - 1, &vops[1]);
              vops.quick_push (else_value);
            }


You can see for reduction operations, the else value is the real value we
need to depend on, we should use "TU" (Undisturbed or merge value) in RVV.
Meaning the inactive elements should remain the "old" value that's why we
use "TU".

However, for single binary operations for example, division, we just only
need to forbid the division operations of the inactive elements in the 
hardware, we don't care the value of the inactive elements value. so in
this case, we want to use "TA". In this case, we want the else value be
a meaningless placeholder in Gimple IR (similar to "undef" or "poison" in
LLVM).

Such meaningless placeholder in the argument of Gimple IR, can be beneficail
for RVV for 2 following reasons:
1. allow us use "TA".
2. Doesn't consume a register.

I am not sure whether we can represent such placeholder in Gimple IR.