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

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

[xuli1 at eswincomputing dot com]

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

            Bug ID: 110751
           Summary: RISC-V: Suport undefined value that allows VSETVL PASS
                    use TA/MA
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xuli1 at eswincomputing dot com
  Target Milestone: ---

Created attachment 55588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55588&action=edit
testcase

Zhong has merged two auto-vectorization patches:
https://github.com/gcc-mirror/gcc/commit/0d4dd7e07a879d6c07a33edb2799710faa95651e
https://github.com/gcc-mirror/gcc/commit/44f244e4672578be6cc513104473981790a1c164


Consider this following case:
#include <stdint-gcc.h>

  __attribute__((noipa))
  void vrem_int8_t (int8_t * __restrict dst, int8_t * __restrict a, int8_t *
__restrict b, int n)
  {
    for (int i = 0; i < n; i++)
      dst[i] = a[i] % b[i];
  }

vrem_int8_t:
  ble a3,zero,.L5
.L3:
  vsetvli a5,a3,e8,m1,tu,ma  --> tu here
  vle8.v v1,0(a1)
  vle8.v v2,0(a2)
  sub a3,a3,a5
  vrem.vv v1,v1,v2
  vse8.v v1,0(a0)
  add a1,a1,a5
  add a2,a2,a5
  add a0,a0,a5
  bne a3,zero,.L3
.L5:
  ret

Currently, the return value of TARGET_PREFERRED_ELSE_VALUE targethook is not
ideal for RVV since it will let VSETVL PASS use MU or TU. We want to suport
undefined value that allows VSETVL PASS use TA/MA.

According to Zhong's advice, there are two approachs:
1.Add a new tree code representing undefined value, like
  DEFTREECODE (UNDEF_TYPE, "undef_type", tcc_type, 0).
2.Modify the targethook TARGET_PREFERRED_ELSE_VALUE to support passing in a GSI
parameter. (Currently only the aarch64 and riscv architectures implement this
hook), In this way, we can build an RVV intrinsic __riscv_vundefine in the
RISCV backend, so that the backend can automatically recognize undefine and use
TA in VSETVL instruction.

Which approach is better? Looking forward to your advice, thanks.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #1 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Thanks Xu take care of this issue.

Since it may need vectorizer support, better listen to both Richards's
suggestions.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |riscv

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
AVX512 can do zeroing or merging (with existing destination contents)
for masked ops, on the GIMPLE side merging would need another source operand
so what we effectively only support is zeroing for AVX512.

I see aarch64 SVE picks the value from specific operands where I'm assuming
that's what the ISA implements (only).

For any suggestion can you please elaborate on what MU/TU and TA/MA are?
Searching for two-letter things in the RVV spec has way to many hits to
find the relevant parts of the spec.

If 'undefined' means there's ISA that leaves the choice to implementors
and that's usually "cheaper" then rather than a new undef_type I always
point to 'error_mark_node' that could be used but you also need a
representation on the RTL side.  I'd also like to add that 'undefined'
is in the end always problematic for an IL.

I would assume that in case 'undefined' allows the implementation to
completely skip operating on a vector subpart, like not issue it, the
actual value will be what's already in the target register so it looks
like "merge" to me but for not skipped subparts that adds a data dependence
on the previous (sub-)register contents (not an issue for "skipped" parts).

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

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so TA is either merge or all-ones.  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?

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

[kito at gcc dot gnu.org]

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.

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

[rguenther at suse dot de]

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?

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rguenther@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.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #7 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rguenther@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?


I am wondering whether we can build a CONST_VECTOR with metadata in the tree
attribute that can be seen in the RTL level during "expand" stage.

For example, can we have some like this:

tree undef = build_zero_cst (vectype)
TREE_ATTRIBUTE (undef) = "undefined"

Then, in the expand stage,

tree t = get_tree (rtx)
if (TREE_ATTRIBUTE (t) == “undefined”) {
...
}

This is my immature idea. Feel free to correct me.

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

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> 
> --- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> (In reply to rguenther@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".

Sure.  For the above case that's obviously correct.

> 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.

As said, just drop the 'else' operand and assign 'unspecified' to its
semantics?  Like we do for .LEN_MASK_LOAD where there isn't any
'else' value and I presume you'll use 'TA' as well there?

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rguenther@suse.de from comment #8)
> On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > 
> > --- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > (In reply to rguenther@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".
> 
> Sure.  For the above case that's obviously correct.
> 
> > 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.
> 
> As said, just drop the 'else' operand and assign 'unspecified' to its
> semantics?  Like we do for .LEN_MASK_LOAD where there isn't any
> 'else' value and I presume you'll use 'TA' as well there?


Yes, LEN_MASK_LOAD doesn't have else value, then we use "TA".

LEN_MASK_LOAD always doesn't have else value.
But COND_LEN_xxx, sometimes has else value (for reduction),
some times doesn't have else value (for division).

Could you tell me how to simulate COND_LEN_xxx that doesn't have else value
like
LEN_MASK_LOAD in consider COND_LEN_xxx pattens may be used in reduction need
else value?

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

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> 
> --- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> (In reply to rguenther@suse.de from comment #8)
> > On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > > 
> > > --- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > > (In reply to rguenther@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".
> > 
> > Sure.  For the above case that's obviously correct.
> > 
> > > 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.
> > 
> > As said, just drop the 'else' operand and assign 'unspecified' to its
> > semantics?  Like we do for .LEN_MASK_LOAD where there isn't any
> > 'else' value and I presume you'll use 'TA' as well there?
> 
> 
> Yes, LEN_MASK_LOAD doesn't have else value, then we use "TA".
> 
> LEN_MASK_LOAD always doesn't have else value.
> But COND_LEN_xxx, sometimes has else value (for reduction),
> some times doesn't have else value (for division).
> 
> Could you tell me how to simulate COND_LEN_xxx that doesn't have else value
> like
> LEN_MASK_LOAD in consider COND_LEN_xxx pattens may be used in reduction need
> else value?

In your target hook simply return NULL_TREE?  The expander should then
omit the else value and you'd have two define_insn, one without
the else value using 'TA' and one with using 'TU' (where it would
match_operand 0).

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #11 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rguenther@suse.de from comment #10)
> On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > 
> > --- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > (In reply to rguenther@suse.de from comment #8)
> > > On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > > > 
> > > > --- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > > > (In reply to rguenther@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".
> > > 
> > > Sure.  For the above case that's obviously correct.
> > > 
> > > > 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.
> > > 
> > > As said, just drop the 'else' operand and assign 'unspecified' to its
> > > semantics?  Like we do for .LEN_MASK_LOAD where there isn't any
> > > 'else' value and I presume you'll use 'TA' as well there?
> > 
> > 
> > Yes, LEN_MASK_LOAD doesn't have else value, then we use "TA".
> > 
> > LEN_MASK_LOAD always doesn't have else value.
> > But COND_LEN_xxx, sometimes has else value (for reduction),
> > some times doesn't have else value (for division).
> > 
> > Could you tell me how to simulate COND_LEN_xxx that doesn't have else value
> > like
> > LEN_MASK_LOAD in consider COND_LEN_xxx pattens may be used in reduction need
> > else value?
> 
> In your target hook simply return NULL_TREE?  The expander should then
> omit the else value and you'd have two define_insn, one without
> the else value using 'TA' and one with using 'TU' (where it would
> match_operand 0).


Oh, I was thinking returning NULL_TREE will cause ICE.

But it worth a try. 

@Li Xu: Could you have a try by followings Richard's suggestion and get
        back to us?

Thanks.

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

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> 
> --- Comment #11 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> (In reply to rguenther@suse.de from comment #10)
> > On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > > 
> > > --- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > > (In reply to rguenther@suse.de from comment #8)
> > > > On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> > > > 
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > > > > 
> > > > > --- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > > > > (In reply to rguenther@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".
> > > > 
> > > > Sure.  For the above case that's obviously correct.
> > > > 
> > > > > 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.
> > > > 
> > > > As said, just drop the 'else' operand and assign 'unspecified' to its
> > > > semantics?  Like we do for .LEN_MASK_LOAD where there isn't any
> > > > 'else' value and I presume you'll use 'TA' as well there?
> > > 
> > > 
> > > Yes, LEN_MASK_LOAD doesn't have else value, then we use "TA".
> > > 
> > > LEN_MASK_LOAD always doesn't have else value.
> > > But COND_LEN_xxx, sometimes has else value (for reduction),
> > > some times doesn't have else value (for division).
> > > 
> > > Could you tell me how to simulate COND_LEN_xxx that doesn't have else value
> > > like
> > > LEN_MASK_LOAD in consider COND_LEN_xxx pattens may be used in reduction need
> > > else value?
> > 
> > In your target hook simply return NULL_TREE?  The expander should then
> > omit the else value and you'd have two define_insn, one without
> > the else value using 'TA' and one with using 'TU' (where it would
> > match_operand 0).
> 
> 
> Oh, I was thinking returning NULL_TREE will cause ICE.

It might need fixups (create the call with one less parameter),
but I think it should be the easiest way to go.

> But it worth a try. 
> 
> @Li Xu: Could you have a try by followings Richard's suggestion and get
>         back to us?
> 
> Thanks.
> 
>

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #13 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
I understand the concern with undefined values, since it then becomes less
obvious whether e.g.:

  a = undef
  b = a == a

is guaranteed to be true, or whether it reduces to:

  b = undef == undef

which is presumably undef.

But I don't think a null operand really helps.  The same question would apply
to:

  x = COND_LEN_ADD (a, b, null, len, bias)
  y = x == x

vs.

  x1 = COND_LEN_ADD (a, b, null, len, bias)
  x2 = COND_LEN_ADD (a, b, null, len, bias)
  y = x1 == x2

Do both of these ys evaluate to true, or is one or both be undefined?

So if we're prepared to accept undefinedness, I'd prefer to have a “proper”
representation of it.  We could probably adopt LLVM's semantics for undef.

(SVE might have some uses for this too.)

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

[rguenther at suse dot de]

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

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

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> 
> rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rsandifo at gcc dot gnu.org
> 
> --- Comment #13 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> I understand the concern with undefined values, since it then becomes less
> obvious whether e.g.:
> 
>   a = undef
>   b = a == a
> 
> is guaranteed to be true, or whether it reduces to:
> 
>   b = undef == undef
> 
> which is presumably undef.
> 
> But I don't think a null operand really helps.  The same question would apply
> to:
> 
>   x = COND_LEN_ADD (a, b, null, len, bias)
>   y = x == x
> 
> vs.
> 
>   x1 = COND_LEN_ADD (a, b, null, len, bias)
>   x2 = COND_LEN_ADD (a, b, null, len, bias)
>   y = x1 == x2
> 
> Do both of these ys evaluate to true, or is one or both be undefined?
> 
> So if we're prepared to accept undefinedness, I'd prefer to have a ?proper?
> representation of it.  We could probably adopt LLVM's semantics for undef.
> 
> (SVE might have some uses for this too.)

Note I simply proposed 'NULL' as the "proper" representation of it.
That doesn't fix any of the semantic issues but I think neither does
any other representation ...

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #15 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I am wondering: do we have have other situations need "undef" value to do
optimizations? If yes, I am aggree with Richard that we need to support "undef"
value.  But "undef" value in Gimple IR support would be a long term work since
it
is not an easy job. For example, in llvm, undef + a -> undef, but undef & a ->
0.

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

[xuli1 at eswincomputing dot com]

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

--- Comment #16 from xuli1 at eswincomputing dot com <xuli1 at eswincomputing dot com> ---
(In reply to rguenther@suse.de from comment #12)
> On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > 
> > --- Comment #11 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > (In reply to rguenther@suse.de from comment #10)
> > > On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > > > 
> > > > --- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > > > (In reply to rguenther@suse.de from comment #8)
> > > > > On Thu, 20 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> > > > > 
> > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> > > > > > 
> > > > > > --- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> > > > > > (In reply to rguenther@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".
> > > > > 
> > > > > Sure.  For the above case that's obviously correct.
> > > > > 
> > > > > > 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.
> > > > > 
> > > > > As said, just drop the 'else' operand and assign 'unspecified' to its
> > > > > semantics?  Like we do for .LEN_MASK_LOAD where there isn't any
> > > > > 'else' value and I presume you'll use 'TA' as well there?
> > > > 
> > > > 
> > > > Yes, LEN_MASK_LOAD doesn't have else value, then we use "TA".
> > > > 
> > > > LEN_MASK_LOAD always doesn't have else value.
> > > > But COND_LEN_xxx, sometimes has else value (for reduction),
> > > > some times doesn't have else value (for division).
> > > > 
> > > > Could you tell me how to simulate COND_LEN_xxx that doesn't have else value
> > > > like
> > > > LEN_MASK_LOAD in consider COND_LEN_xxx pattens may be used in reduction need
> > > > else value?
> > > 
> > > In your target hook simply return NULL_TREE?  The expander should then
> > > omit the else value and you'd have two define_insn, one without
> > > the else value using 'TA' and one with using 'TU' (where it would
> > > match_operand 0).
> > 
> > 
> > Oh, I was thinking returning NULL_TREE will cause ICE.
> 
> It might need fixups (create the call with one less parameter),
> but I think it should be the easiest way to go.
> 
> > But it worth a try. 
> > 
> > @Li Xu: Could you have a try by followings Richard's suggestion and get
> >         back to us?
> > 
> > Thanks.
> > 
> >

OK.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #15)
> I am wondering: do we have have other situations need "undef" value to do
> optimizations? If yes, I am aggree with Richard that we need to support
> "undef"
> value.  But "undef" value in Gimple IR support would be a long term work
> since it
> is not an easy job. For example, in llvm, undef + a -> undef, but undef & a
> -> 0.

We do have "undef" in the GIMPLE IR, for SSA variables it's the default
definition.

Note I think that a formal "undef" is different from "unspecified"
(or in this case "target specified").  In GIMPLE an "undef" use is
invoking undefined behavior but clearly doing a MASK/LEN operation
with some "undef" lanes and then operating on the vector is _not_
invoking undefined behavior.  In fact with RVV intrinsics the programmer
can rely on RVV semantics, thus either all-ones _or_ merge which means
if you know the old value has some specific bits set you know the new
value will as well.  That's _not_ "undef" in the classical sense so
I think LLVMs "undef" isn't a very good fit here (nor would putting
a SSA default def as the "else" value).

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

[rsandifo at gcc dot gnu.org]

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.

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

[rguenth at gcc dot 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.

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

[rsandifo at gcc dot gnu.org]

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

--- Comment #20 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #19)
> 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).
Yeah, that's fair.

For the ifn->optab interface, I think it'd be natural to use an actual rtx
rather than a null pointer, since e.g. predicates are not set up to handle
nulls.  So perhaps we should start the process there.  We could add an UNDEF
rtl code that is initially only used for the ifn->optab interface, and expand
it as we find new use cases.  We can grow the semantics based on those use
cases and based on LLVM's experience.

> 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.
One of the main optimisations I wanted from that was:
  a = IFN_MASK_LOAD (…, mask)
  b = VEC_COND_EXPR <mask, a, {0,0,…}>
→
  a = IFN_MASK_LOAD (…, mask)
  b = a
which wouldn't be valid for undef.

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

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 21 Jul 2023, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> 
> --- Comment #20 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #19)
> > 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).
> Yeah, that's fair.
> 
> For the ifn->optab interface, I think it'd be natural to use an actual rtx
> rather than a null pointer, since e.g. predicates are not set up to handle
> nulls.  So perhaps we should start the process there.  We could add an UNDEF
> rtl code that is initially only used for the ifn->optab interface, and expand
> it as we find new use cases.  We can grow the semantics based on those use
> cases and based on LLVM's experience.
> 
> > 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.
> One of the main optimisations I wanted from that was:
>   a = IFN_MASK_LOAD (?, mask)
>   b = VEC_COND_EXPR <mask, a, {0,0,?}>
> ?
>   a = IFN_MASK_LOAD (?, mask)
>   b = a
> which wouldn't be valid for undef.

Right.  It would be valid to do

  b = IFN_MASK_LOAD (?, mask, {0,0,?});

if we add ELSE to IFN_MASK_LOAD.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #22 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rsandifo@gcc.gnu.org from comment #20)
> (In reply to Richard Biener from comment #19)
> > 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).
> Yeah, that's fair.
> 
> For the ifn->optab interface, I think it'd be natural to use an actual rtx
> rather than a null pointer, since e.g. predicates are not set up to handle
> nulls.  So perhaps we should start the process there.  We could add an UNDEF
> rtl code that is initially only used for the ifn->optab interface, and
> expand it as we find new use cases.  We can grow the semantics based on
> those use cases and based on LLVM's experience.
> 
> > 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.
> One of the main optimisations I wanted from that was:
>   a = IFN_MASK_LOAD (…, mask)
>   b = VEC_COND_EXPR <mask, a, {0,0,…}>
> →
>   a = IFN_MASK_LOAD (…, mask)
>   b = a
> which wouldn't be valid for undef.

In RVV, we define a "undef" rtx which is:

            (unspec:V256HF [
                    (reg:SI 0 zero)
                ] UNSPEC_VUNDEF)


So, RVV pattern as defined as follows:

(define_insn "@pred_<optab><mode>"
  [(set (match_operand:VI 0 "register_operand"          "=vd,vd, vr, vr")
        (if_then_else:VI
          (unspec:<VM>
            [(match_operand:<VM> 1 "vector_mask_operand" "vm,vm,Wc1,Wc1")
             (match_operand 4 "vector_length_operand"    "rK,rK, rK, rK")
             (match_operand 5 "const_int_operand"        " i, i,  i,  i")
             (match_operand 6 "const_int_operand"        " i, i,  i,  i")
             (match_operand 7 "const_int_operand"        " i, i,  i,  i")
             (reg:SI VL_REGNUM)
             (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
          (any_int_unop:VI
            (match_operand:VI 3 "register_operand"       "vr,vr, vr, vr"))
          (match_operand:VI 2 "vector_merge_operand"     "vu, 0, vu,  0")))]
  "TARGET_VECTOR"
  "v<insn>.v\t%0,%3%p1"
  [(set_attr "type" "vialu")
   (set_attr "mode" "<MODE>")
   (set_attr "vl_op_idx" "4")
   (set (attr "ta") (symbol_ref "riscv_vector::get_ta(operands[5])"))
   (set (attr "ma") (symbol_ref "riscv_vector::get_ma(operands[6])"))
   (set (attr "avl_type") (symbol_ref "INTVAL (operands[7])"))])

You can see operand:

(match_operand:VI 2 "vector_merge_operand"     "vu, 0, vu,  0")


There is a constraint "vu": 

(define_constraint "vu"
  "A undefined vector value."
  (and (match_code "unspec")
       (match_test "XINT (op, 1) == UNSPEC_VUNDEF")))


RA will match constraint "vu" for "undef" else value.

(insn 10 9 0 2 (set (mem:V256HF (reg/v/f:DI 136 [ out ]) [1 MEM[(v256hf
*)out_4(D)]+0 S512 A128])
        (if_then_else:V256HF (unspec:V256BI [
                    (const_vector:V256BI [
                            (const_int 1 [0x1]) repeated x256
                        ])
                    (reg:DI 138)
                    (const_int 2 [0x2]) repeated x2
                    (const_int 0 [0])
                    (reg:SI 66 vl)
                    (reg:SI 67 vtype)
                ] UNSPEC_VPREDICATE)
            (reg/v:V256HF 134 [ v ])
            (unspec:V256HF [
                    (reg:SI 0 zero)
                ] UNSPEC_VUNDEF))) "rvv.c":18:17 1156 {pred_movv256hf}
     (nil))

You can see:
            (unspec:V256HF [
                    (reg:SI 0 zero)
                ] UNSPEC_VUNDEF)


Then such operand will not consume a register.

This is currently how RVV model "undef" in RTL backend.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #23 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Hi, Richard and Richi.

I found a way to simulate "undefine" in COND_LEN_xxx pattern for the ELSE value
that doesn't matter.

First, return size type 0 in else_value target hook:

/* Use size_type 0 which is represented as const0_rtx in RTL to simulate
   undefine else value since GCC doesn't undefine value in TREE/GIMPLE
   representation.

   TODO: We may will need to support undefine value in TREE/GIMPLE middle-end
   IR. But current approach is good enough for RVV codegen/performance.  */
static tree
riscv_preferred_else_value (unsigned ifn, tree vectype, unsigned int nops,
                            tree *ops)
{
  if (riscv_v_ext_mode_p (TYPE_MODE (vectype)))
    return build_zero_cst (size_type_node);

  return default_preferred_else_value (ifn, vectype, nops, ops);
}

Note that we can't return VECTOR_CST with all 0. 
Since a VECTROR_CST with all 0 may matter and the real value we need.

So, to simulate "undefine", I pass a '0' which will be represented as
const0_rtx in RTX.

So the IR will be:

vect__7.12_8 = .COND_LEN_DIV ({ -1, ... }, vect__4.8_22, vect__6.11_9, 0
(undefine ELSE value), _37, 0);

Then I relax the predicate in COND_LEN_xxx pattern. It works and pass all
the tests.

Consider this following case:

void
foo (int32_t *__restrict a, int32_t *__restrict b, int n)
{
  for (int i = 0; i < n; i++)
    a[i] = a[i] / b[i];
}

Before:
foo:
        ble     a2,zero,.L5
        mv      a4,a0
        vsetvli a5,zero,e32,m8,ta,ma
        vmv.v.i v4,0
.L3:
        vsetvli a5,a2,e32,m8,tu,ma
        vmv8r.v v1,v4
        slli    a3,a5,2
        vle32.v v3,0(a0)
        vle32.v v2,0(a1)
        sub     a2,a2,a5
        vdiv.vv v1,v3,v2
        vse32.v v1,0(a4)
        add     a0,a0,a3
        add     a1,a1,a3
        add     a4,a4,a3
        bne     a2,zero,.L3
.L5:
        ret

After:

foo:
        ble     a2,zero,.L5
        mv      a4,a0
.L3:
        vsetvli a5,a2,e32,m8,ta,ma
        slli    a3,a5,2
        vle32.v v8,0(a0)
        vle32.v v16,0(a1)
        sub     a2,a2,a5
        vdiv.vv v8,v8,v16
        vse32.v v8,0(a4)
        add     a0,a0,a3
        add     a1,a1,a3
        add     a4,a4,a3
        bne     a2,zero,.L3
.L5:
        ret


Not so elegant. But it does fix the performance/codegen issue in RVV.

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

[rsandifo at gcc dot gnu.org]

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

--- Comment #24 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Heh, nice hack. :)  But I guess this shows that the type checking of
internal functions isn't as strong it should be.

IMO it's wrong to pass a scalar else value to a vector operation.
Even if it happens to work now, it's likely to fail in the future.
E.g. I think match.pd fold rules should be entitled to assume
(without checking) that all data operands to a COND_* function
have compatible types.

If we want an undefined operand value, I think we'll need add to
add one that specifically has that meaning.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #25 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rsandifo@gcc.gnu.org from comment #24)
> Heh, nice hack. :)  But I guess this shows that the type checking of
> internal functions isn't as strong it should be.
> 
> IMO it's wrong to pass a scalar else value to a vector operation.
> Even if it happens to work now, it's likely to fail in the future.
> E.g. I think match.pd fold rules should be entitled to assume
> (without checking) that all data operands to a COND_* function
> have compatible types.
> 
> If we want an undefined operand value, I think we'll need add to
> add one that specifically has that meaning.

Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments
type are compatible for COND_LEN_xxx in the future (Currently, it's obviously
not checking this). Then, it will cause ICE.

Adding undefine value will be the optimal solution.
However, it will be a big project:
1. Add undefine in tree.def
2. Add undefine in RTL representation.
3. Adjust each PASS to handle undefine value.
4. Adjust register allocation to handle undefine value.
... etc

I can image it will be long term project to support undefine.
But we want to fix this inferior codegen of RVV currently since
I have tested various benchmark, the ELSE value hurt the performance
so much so that I want to use current infrastructure GCC to fix
this issue.

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

[rsandifo at gcc dot gnu.org]

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

--- Comment #26 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
But this is how technical debt builds up.  We'd be making a change
that doesn't match the type system, and that we know to be wrong
in principle.  And we'd be making it with no realistic prospect
that it will be cleaned up later.

> Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments
> type are compatible for COND_LEN_xxx in the future (Currently, it's obviously
> not checking this). Then, it will cause ICE.

Yeah.  But like I say, I don't think that's the most worrying
scenario.  For me the most worrying scenario is that a match.pd
fold will say that:

  (cond_len all-false a b c len bias)

folds to c without checking whether c is compatible with the return
type.  And IMO it shouldn't need to check that the type is compatible.

If a rule like that triggers after this patch goes in, the pressure
will be to continue to support the hack and add workarounds for it.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #27 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rsandifo@gcc.gnu.org from comment #26)
> But this is how technical debt builds up.  We'd be making a change
> that doesn't match the type system, and that we know to be wrong
> in principle.  And we'd be making it with no realistic prospect
> that it will be cleaned up later.
> 
> > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments
> > type are compatible for COND_LEN_xxx in the future (Currently, it's obviously
> > not checking this). Then, it will cause ICE.
> 
> Yeah.  But like I say, I don't think that's the most worrying
> scenario.  For me the most worrying scenario is that a match.pd
> fold will say that:
> 
>   (cond_len all-false a b c len bias)
> 
> folds to c without checking whether c is compatible with the return
> type.  And IMO it shouldn't need to check that the type is compatible.
> 
> If a rule like that triggers after this patch goes in, the pressure
> will be to continue to support the hack and add workarounds for it.

Thanks Richard a lot.

But I don't think we need to worry about the fold COND_LEN into
the ELSE_VALUE.

Let's back to the previous comments you gave for COND_LEN_xxx:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html

Following your suggestions, I support cond_len_xxx by following your (1):

(1) RVV implements cond_* optabs as expanders.  RVV therefore supports
    both IFN_COND_ADD and IFN_COND_LEN_ADD.  No dummy length arguments
    are needed at the gimple level.

I use this approach to support COND_LEN_xxx since last time you have mentioned
we will need more work in GIMPLE FOLD and other things.

To simplify the implementation of COND_LEN_xxx. We support both COND_XXX and
COND_LEN_XXX in RISC-V backend. 

We don't have COND_LEN_xxx with dummy length (All dummy length case will go
back to COND_XXX).  So we forbid the case that FOLD COND_LEN_xxx into ELSE
value since COND_LEN_xxx is built always with a meaning length.

The only GIMPLE FOLD optimization of COND_LEN_XXX is operations fusion, meaning
FOLD cond_len_mult + cond_len_add into ==> cond_len_fma. That's what I am worry
about. But currently it works fine (I have tests to test that).

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #28 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to JuzheZhong from comment #27)
> (In reply to rsandifo@gcc.gnu.org from comment #26)
> > But this is how technical debt builds up.  We'd be making a change
> > that doesn't match the type system, and that we know to be wrong
> > in principle.  And we'd be making it with no realistic prospect
> > that it will be cleaned up later.
> > 
> > > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments
> > > type are compatible for COND_LEN_xxx in the future (Currently, it's obviously
> > > not checking this). Then, it will cause ICE.
> > 
> > Yeah.  But like I say, I don't think that's the most worrying
> > scenario.  For me the most worrying scenario is that a match.pd
> > fold will say that:
> > 
> >   (cond_len all-false a b c len bias)
> > 
> > folds to c without checking whether c is compatible with the return
> > type.  And IMO it shouldn't need to check that the type is compatible.
> > 
> > If a rule like that triggers after this patch goes in, the pressure
> > will be to continue to support the hack and add workarounds for it.
> 
> Thanks Richard a lot.
> 
> But I don't think we need to worry about the fold COND_LEN into
> the ELSE_VALUE.
> 
> Let's back to the previous comments you gave for COND_LEN_xxx:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html
> 
> Following your suggestions, I support cond_len_xxx by following your (1):
> 
> (1) RVV implements cond_* optabs as expanders.  RVV therefore supports
>     both IFN_COND_ADD and IFN_COND_LEN_ADD.  No dummy length arguments
>     are needed at the gimple level.
> 
> I use this approach to support COND_LEN_xxx since last time you have
> mentioned
> we will need more work in GIMPLE FOLD and other things.
> 
> To simplify the implementation of COND_LEN_xxx. We support both COND_XXX and
> COND_LEN_XXX in RISC-V backend. 
> 
> We don't have COND_LEN_xxx with dummy length (All dummy length case will go
> back to COND_XXX).  So we forbid the case that FOLD COND_LEN_xxx into ELSE
> value since COND_LEN_xxx is built always with a meaning length.
> 
> The only GIMPLE FOLD optimization of COND_LEN_XXX is operations fusion,
> meaning
> FOLD cond_len_mult + cond_len_add into ==> cond_len_fma. That's what I am
> worry about. But currently it works fine (I have tests to test that).

Moreover, Maybe we will need to worry about COND_XXX into ELSE_VALUE if I
return
scalar 0 in the else targethook.

However, for RVV, we always use COND_LEN_xxx in the loop vectorizer which may
build with the argument from the ELSE_VALUE targethook.

The only situation we will use COND_XXX is the UNCOND_OP + VEC_COND_EXPR ->
COND_XXX in match.pd which always has a real ELSE VALUE.

After these analysis, it seems that there is no risks?

Not sure whether I am correct or not.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #29 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to JuzheZhong from comment #27)
> (In reply to rsandifo@gcc.gnu.org from comment #26)
> > But this is how technical debt builds up.  We'd be making a change
> > that doesn't match the type system, and that we know to be wrong
> > in principle.  And we'd be making it with no realistic prospect
> > that it will be cleaned up later.
> > 
> > > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments
> > > type are compatible for COND_LEN_xxx in the future (Currently, it's obviously
> > > not checking this). Then, it will cause ICE.
> > 
> > Yeah.  But like I say, I don't think that's the most worrying
> > scenario.  For me the most worrying scenario is that a match.pd
> > fold will say that:
> > 
> >   (cond_len all-false a b c len bias)
> > 
> > folds to c without checking whether c is compatible with the return
> > type.  And IMO it shouldn't need to check that the type is compatible.
> > 
> > If a rule like that triggers after this patch goes in, the pressure
> > will be to continue to support the hack and add workarounds for it.
> 
> Thanks Richard a lot.
> 
> But I don't think we need to worry about the fold COND_LEN into
> the ELSE_VALUE.
> 
> Let's back to the previous comments you gave for COND_LEN_xxx:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html
> 
> Following your suggestions, I support cond_len_xxx by following your (1):
> 
> (1) RVV implements cond_* optabs as expanders.  RVV therefore supports
>     both IFN_COND_ADD and IFN_COND_LEN_ADD.  No dummy length arguments
>     are needed at the gimple level.
> 
> I use this approach to support COND_LEN_xxx since last time you have
> mentioned
> we will need more work in GIMPLE FOLD and other things.
> 
> To simplify the implementation of COND_LEN_xxx. We support both COND_XXX and
> COND_LEN_XXX in RISC-V backend. 
> 
> We don't have COND_LEN_xxx with dummy length (All dummy length case will go
> back to COND_XXX).  So we forbid the case that FOLD COND_LEN_xxx into ELSE
> value since COND_LEN_xxx is built always with a meaning length.
> 
> The only GIMPLE FOLD optimization of COND_LEN_XXX is operations fusion,
> meaning
> FOLD cond_len_mult + cond_len_add into ==> cond_len_fma. That's what I am
> worry about. But currently it works fine (I have tests to test that).

Sorry. I am wrong about the comments.

The COND_LEN_xxx for GIMPLE FOLD should be like:

NEG + COND_LEN_FMA -> COND_LEN_FNMA ....etc operations fusion.

And since the length is never a dummy length (we always use COND_XXX to build
for dummy length situation), we forbid COND_LEN_xxx into any argument in FOLD.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #30 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Hi.Richard.

I understand your conern:

If we are possible have this following possible rule to fold to ELSE value in
the future:

1. (cond_len all-false a b c len bias)
2. (cond_len any mask a b c len bias) (len + bias == 0)


I think it also can be easily fixed in the backend by ELSE_VALUE targethook.

We can return scalar 0 for else value only if (ops[0] != all false mask &&
LEN+BIAS ！= 0).

Am I right?

Thanks.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
On GIMPLE an "undefined" operand representation would be the default definition
of an SSA name with the appropriate type.  That's a somewhat "heavy"
representation and it also doesn't fit the target hook return value nicely,
but we could handle a NULL_TREE return value from the target hook in the
way to create such SSA name.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #32 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #31)
> On GIMPLE an "undefined" operand representation would be the default
> definition of an SSA name with the appropriate type.  That's a somewhat
> "heavy" representation and it also doesn't fit the target hook return value
> nicely,
> but we could handle a NULL_TREE return value from the target hook in the
> way to create such SSA name.

Thanks Richi.

How does this special "SSA" represent in RTX or How could I recognize this is
a "undefine" value in "expand" stage ?

I wondering whether my approach (passing a scalar 0) to the ELSE value which is
easily recognized in RTL backend ("expand stage") is suitable ? 

Since you could see there will be one more move instruction inside the loop
which hurt vector performance a lot, I want to find a quick way to fix it for
now.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #33 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Is it reasonable this way ?


ELSE VALUE = make_temp_ssa_name (vectype, NULL, "undefine_");

Then in the later "expand" stage:


defind_expand "cond_len_xxx"
...


if (REG_EXPR (operand) == "undefine") {
gen rvv insns with no else value
}

Is it reasonable?

Thanks.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> ---
The ELSE value of type TYPE would be constructed like

 tree var = create_tmp_var (type);
 tree else_val = get_or_create_ssa_default_def (cfun, var);

I'm not sure const0_rtx is a good representation on RTL - how would
you distinguish that from a conditional operation on an integer vector
with else value zero?  Say for an integer division?

 for (i)
   if (f[i])
     y[i] = x[i] / z[i];
   else
     y[i] = 0;

we don't have a separate "else" value for elements cut off via 'len'
vs. elements cut off via 'mask'.

On RTL there are "special" RTXen used for this kind of stuff, like
(use:mode ..) or (clobber const0_rtx), but I'm the wrong person to
ask which one would be most appropriate for a general operand in
an otherwise generic instruction.  Maybe Richard has a guess.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #34)
> The ELSE value of type TYPE would be constructed like
> 
>  tree var = create_tmp_var (type);
>  tree else_val = get_or_create_ssa_default_def (cfun, var);

Oh, and you recognize that at expansion by

  TREE_CODE (else_val) == SSA_NAAME
  && SSA_NAME_IS_DEFAULT_DEF (else_val)
  && VAR_P (SSA_NAME_VAR (else_val))

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #36 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #34)
> The ELSE value of type TYPE would be constructed like
> 
>  tree var = create_tmp_var (type);
>  tree else_val = get_or_create_ssa_default_def (cfun, var);
> 
> I'm not sure const0_rtx is a good representation on RTL - how would
> you distinguish that from a conditional operation on an integer vector
> with else value zero?  Say for an integer division?

My current approach is that I passed scalar 0 to the ELSE VALUE.

So in the I relax the operand predicate of the cond_len else operand:

it can be either a register_operand has VECTOR_MODE or a const_int 0 (Note that
it
can't be the CONST_VECTOR).

So, I can distinguish the else operand. If it is a scalar const_int 0, it is
undefine. Otherwise, it is always a register operand with a vector mode.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #37 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #35)
> (In reply to Richard Biener from comment #34)
> > The ELSE value of type TYPE would be constructed like
> > 
> >  tree var = create_tmp_var (type);
> >  tree else_val = get_or_create_ssa_default_def (cfun, var);
> 
> Oh, and you recognize that at expansion by
> 
>   TREE_CODE (else_val) == SSA_NAAME
>   && SSA_NAME_IS_DEFAULT_DEF (else_val)
>   && VAR_P (SSA_NAME_VAR (else_val))

Oh. Sounds good. I will have a try.

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

[rguenther at suse dot de]

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

--- Comment #38 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 13 Sep 2023, juzhe.zhong at rivai dot ai wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
> 
> --- Comment #36 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> (In reply to Richard Biener from comment #34)
> > The ELSE value of type TYPE would be constructed like
> > 
> >  tree var = create_tmp_var (type);
> >  tree else_val = get_or_create_ssa_default_def (cfun, var);
> > 
> > I'm not sure const0_rtx is a good representation on RTL - how would
> > you distinguish that from a conditional operation on an integer vector
> > with else value zero?  Say for an integer division?
> 
> My current approach is that I passed scalar 0 to the ELSE VALUE.
> 
> So in the I relax the operand predicate of the cond_len else operand:
> 
> it can be either a register_operand has VECTOR_MODE or a const_int 0 (Note that
> it
> can't be the CONST_VECTOR).

I see.

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

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|richard.sandiford at arm dot com   |

--- Comment #39 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #34)
> On RTL there are "special" RTXen used for this kind of stuff, like
> (use:mode ..) or (clobber const0_rtx), but I'm the wrong person to
> ask which one would be most appropriate for a general operand in
> an otherwise generic instruction.  Maybe Richard has a guess.
I think the best bet with existing RTL is (scratch:<MODE>).  It's not an exact
fit for current usage (or for the documentation), but it's similar in spirit to
the cratch in (mem:BLK (scratch:P)) (which also isn't an exact match for the
documentation).

I don't expect this to work out of the box.  Some changes to target-independent
code will be needed.  But if we restrict this use to expanders for now, the
changes should be relatively small.  I think the main thing would be to make
maybe_legitimize_operand turn a scratch rtx into a fresh pseudo if the
predicate doesn't accept a scratch.  We'd then be restoring the semantics of an
uninitialised SSA_NAME.

If we did that, I think we could convert uninitialised SSA_NAMEs into SCRATCHes
for everything that goes through expand_fn_using_insn.  There should be no need
to restrict it to COND_* functions.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #40 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I try this following code to set ELSE_VALUE:

static tree
riscv_preferred_else_value (unsigned ifn, tree vectype, unsigned int nops,
                            tree *ops)
{
  if (riscv_v_ext_mode_p (TYPE_MODE (vectype)))
    {
      // return build_zero_cst (size_type_node);
      return get_or_create_ssa_default_def (cfun, create_tmp_var (vectype));
    }

  return default_preferred_else_value (ifn, vectype, nops, ops);
}

It generate the GIMPLE IR ELSE VALUE is an uninitialized value:

vector([128,128]) signed char D.2821;
vector([128,128]) signed char _72(D);
vect_patt_42.12_73 = .COND_LEN_MOD ({ -1, ... }, vect__3.8_67, vect__6.11_71,
_72(D), _82, 0);

Then "_72" is expanded into RTL as:

(reg:RVVM8QI 136 [ D.2821 ])

I try to use SSA_NAME_IS_DEFAULT_DEF to check whether this operand is 
the undef value since:

(gdb) p ops[4]->u->reg->attrs->decl->base.default_def_flag
$7 = 0

It's false that I can't recognize it as "undefine" value.

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

[richard.sandiford at arm dot com]

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

--- Comment #41 from richard.sandiford at arm dot com ---
"juzhe.zhong at rivai dot ai" <gcc-bugzilla@gcc.gnu.org> writes:
> I try this following code to set ELSE_VALUE:
>
> static tree
> riscv_preferred_else_value (unsigned ifn, tree vectype, unsigned int nops,
>                             tree *ops)
> {
>   if (riscv_v_ext_mode_p (TYPE_MODE (vectype)))
>     {
>       // return build_zero_cst (size_type_node);
>       return get_or_create_ssa_default_def (cfun, create_tmp_var (vectype));
>     }
>
>   return default_preferred_else_value (ifn, vectype, nops, ops);
> }
>
> It generate the GIMPLE IR ELSE VALUE is an uninitialized value:
>
> vector([128,128]) signed char D.2821;
> vector([128,128]) signed char _72(D);
> vect_patt_42.12_73 = .COND_LEN_MOD ({ -1, ... }, vect__3.8_67, vect__6.11_71,
> _72(D), _82, 0);
>
> Then "_72" is expanded into RTL as:
>
> (reg:RVVM8QI 136 [ D.2821 ])
>
> I try to use SSA_NAME_IS_DEFAULT_DEF to check whether this operand is 
> the undef value since:
>
> (gdb) p ops[4]->u->reg->attrs->decl->base.default_def_flag
> $7 = 0
>
> It's false that I can't recognize it as "undefine" value.
IMO it's expand_fn_using_insn that should be recognising the default def,
not the target.  It can then use a SCRATCH rtx as the operand (but see
my previous comment for more about that).

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #42 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

https://gcc.gnu.org/g:27282dc0931484c31fa391772499d878afcc746a

commit r14-4179-g27282dc0931484c31fa391772499d878afcc746a
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date:   Wed Sep 20 22:58:49 2023 +0800

    internal-fn: Support undefined rtx for uninitialized SSA_NAME[PR110751]

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

    As Richard and Richi suggested, we recognize uninitialized SSA_NAME and
convert it
    into SCRATCH rtx if the target predicate allows SCRATCH.

    It can help to reduce redundant data move instructions of targets like
RISC-V.

    Bootstrap and Regression on x86 passed.

    gcc/ChangeLog:
            PR target/110751

            * internal-fn.cc (expand_fn_using_insn): Support undefined rtx
value.
            * optabs.cc (maybe_legitimize_operand): Ditto.
            (can_reuse_operands_p): Ditto.
            * optabs.h (enum expand_operand_type): Ditto.
            (create_undefined_input_operand): Ditto.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #43 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Lehua Ding <lhtin@gcc.gnu.org>:

https://gcc.gnu.org/g:9b5b2c9f95056f97cf95f0e8d970015aa586497b

commit r14-4194-g9b5b2c9f95056f97cf95f0e8d970015aa586497b
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date:   Thu Sep 21 15:19:29 2023 +0800

    RISC-V: Enable undefined support for RVV auto-vectorization[PR110751]

    Now GCC middle-end can support undefined value which is traslated into
(scratch:mode).

    This patch is to enable RISC-V backend undefine value in ELSE value of
COND_LEN_xxx/COND_xxx.

    Consider this following case:

      __attribute__((noipa))
      void vrem_int8_t (int8_t * __restrict dst, int8_t * __restrict a, int8_t
* __restrict b, int n)
      {
        for (int i = 0; i < n; i++)
          dst[i] = a[i] % b[i];
      }

    Before this patch:

    vrem_int8_t:
            ble     a3,zero,.L5
            vsetvli a5,zero,e8,m1,ta,ma
            vmv.v.i v4,0                          ---> redundant.
    .L3:
            vsetvli a5,a3,e8,m1,tu,ma             ---> should be TA.
            vmv1r.v v1,v4                         ---> redudant.
            vle8.v  v3,0(a1)
            vle8.v  v2,0(a2)
            sub     a3,a3,a5
            vrem.vv v1,v3,v2
            vse8.v  v1,0(a0)
            add     a1,a1,a5
            add     a2,a2,a5
            add     a0,a0,a5
            bne     a3,zero,.L3
    .L5:
            ret

    After this patch:

    vrem_int8_t:
            ble     a3,zero,.L5
    .L3:
            vsetvli a5,a3,e8,m1,ta,ma
            vle8.v  v1,0(a1)
            vle8.v  v2,0(a2)
            sub     a3,a3,a5
            vrem.vv v1,v1,v2
            vse8.v  v1,0(a0)
            add     a1,a1,a5
            add     a2,a2,a5
            add     a0,a0,a5
            bne     a3,zero,.L3
    .L5:
            ret

            PR target/110751

    gcc/ChangeLog:

            * config/riscv/autovec.md: Enable scratch rtx in ELSE operand.
            * config/riscv/predicates.md (autovec_else_operand): New predicate.
            * config/riscv/riscv-v.cc (get_else_operand): New function.
            (expand_cond_len_unop): Adapt ELSE value.
            (expand_cond_len_binop): Ditto.
            (expand_cond_len_ternop): Ditto.
            * config/riscv/riscv.cc (riscv_preferred_else_value): New function.
            (TARGET_PREFERRED_ELSE_VALUE): New targethook.

    gcc/testsuite/ChangeLog:

            * gcc.target/riscv/rvv/autovec/binop/vdiv-rv32gcv-nofm.c: Adapt
test.
            * gcc.target/riscv/rvv/autovec/binop/vdiv-rv32gcv.c: Ditto.
            * gcc.target/riscv/rvv/autovec/binop/vdiv-rv64gcv-nofm.c: Ditto.
            * gcc.target/riscv/rvv/autovec/binop/vdiv-rv64gcv.c: Ditto.
            * gcc.target/riscv/rvv/autovec/binop/vrem-rv32gcv.c: Ditto.
            * gcc.target/riscv/rvv/autovec/binop/vrem-rv64gcv.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-1.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-10.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-11.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-12.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-2.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-3.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-4.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-5.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-6.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-7.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-8.c: Ditto.
            * gcc.target/riscv/rvv/autovec/ternop/ternop_nofm-9.c: Ditto.

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

[juzhe.zhong at rivai dot ai]

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

--- Comment #44 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Fixed on the trunk.

Hi, LiXu. Could you verify it with trunk GCC and close this PR?

Thanks

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

[xuli1 at eswincomputing dot com]

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

xuli1 at eswincomputing dot com <xuli1 at eswincomputing dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #45 from xuli1 at eswincomputing dot com <xuli1 at eswincomputing dot com> ---
Verified

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

[xuli1 at eswincomputing dot com]

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

xuli1 at eswincomputing dot com <xuli1 at eswincomputing dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #46 from xuli1 at eswincomputing dot com <xuli1 at eswincomputing dot com> ---
closed