[Bug c/111751] New: RISC-V: RVV unexpected vectorization

[Bug c/111751] New: RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

            Bug ID: 111751
           Summary: RISC-V: RVV unexpected vectorization
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

#include <stdlib.h>

#define N 16

int main ()
{
  int i;
  char ia[N];
  char ic[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
  char ib[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};

  /* Not vectorizable, multiplication */
  for (i = 0; i < N; i++)
    {
      ia[i] = ib[i] * ic[i];
    }

  /* check results:  */
  for (i = 0; i < N; i++)
    {
      if (ia[i] != (char) (ib[i] * ic[i]))
        abort ();
    }

  return 0;
}

RVV GCC ASM:

main:
        lui     a5,%hi(.LANCHOR0)
        addi    a5,a5,%lo(.LANCHOR0)
        addi    sp,sp,-48
        ld      a4,0(a5)
        ld      a5,8(a5)
        sd      a5,8(sp)
        sd      a5,24(sp)
        sd      ra,40(sp)
        addi    a5,sp,16
        sd      a4,0(sp)
        sd      a4,16(sp)
        vsetivli        zero,16,e8,m1,ta,ma
        vle8.v  v1,0(a5)
        vle8.v  v2,0(sp)
        vmul.vv v1,v1,v2
        vmv.x.s a5,v1
        andi    a5,a5,0xff
        bne     a5,zero,.L2
        vslidedown.vi   v2,v1,1
        li      a4,9
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,2
        li      a4,36
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,3
        li      a4,81
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,4
        li      a4,144
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,5
        li      a4,225
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,6
        li      a4,68
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,7
        li      a4,185
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,8
        li      a4,64
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,9
        li      a4,217
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,10
        li      a4,132
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,11
        li      a4,65
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,12
        li      a4,16
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,13
        li      a4,241
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v2,v1,14
        li      a4,228
        vmv.x.s a5,v2
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        vslidedown.vi   v1,v1,15
        li      a4,233
        vmv.x.s a5,v1
        andi    a5,a5,0xff
        bne     a5,a4,.L2
        ld      ra,40(sp)
        li      a0,0
        addi    sp,sp,48
        jr      ra
.L2:
        call    abort


ARM SVE GCC:

main:
        mov     w0, 0
        ret

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
AARCH64 did vectorize the code just using non-SVE which then allowed to be
optimized too.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-10-10
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
If you add `-fno-vect-cost-model` to aarch64 compiling, then it uses SVE and
does not optimize to just `return 0`.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The issue for aarch64 with SVE is that MASK_LOAD is not optimized:

  ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
  ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
  vect__1.7_9 = .MASK_LOAD (&ib, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... });
  vect__2.10_35 = .MASK_LOAD (&ic, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...
});

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Andrew Pinski from comment #4)
> The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> 
>   ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
>   ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
>   vect__1.7_9 = .MASK_LOAD (&ib, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> ... });
>   vect__2.10_35 = .MASK_LOAD (&ic, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> ... });

I don't ARM SVE has issues ...
If we can choose fixed length vector mode to vectorize it, it will be well
optimized.

I think this is RISC-V target dependent issue.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> > 
> >   ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> >   ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> >   vect__1.7_9 = .MASK_LOAD (&ib, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > ... });
> >   vect__2.10_35 = .MASK_LOAD (&ic, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > ... });
> 
> I don't ARM SVE has issues ...

It does as I mentioned if you use -fno-vect-cost-model, you get the above issue
which should be optimized really to a constant vector ...

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

--- Comment #7 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Andrew Pinski from comment #6)
> (In reply to JuzheZhong from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> > > 
> > >   ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > >   ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> > >   vect__1.7_9 = .MASK_LOAD (&ib, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > ... });
> > >   vect__2.10_35 = .MASK_LOAD (&ic, 8B, { -1, -1, -1, -1, -1, -1, -1, -1, -1,
> > > -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > > ... });
> > 
> > I don't ARM SVE has issues ...
> 
> It does as I mentioned if you use -fno-vect-cost-model, you get the above
> issue which should be optimized really to a constant vector ...

After investigation:

I found it failed to recognize its CONST_VECTOR value in FRE

/* Visit a load from a reference operator RHS, part of STMT, value number it,
   and return true if the value number of the LHS has changed as a result.  */

static bool
visit_reference_op_load (tree lhs, tree op, gimple *stmt)
{
  bool changed = false;
  tree result;
  vn_reference_t res;

  tree vuse = gimple_vuse (stmt);
  tree last_vuse = vuse;
  result = vn_reference_lookup (op, vuse, default_vn_walk_kind, &res, true,
&last_vuse);

  /* We handle type-punning through unions by value-numbering based
     on offset and size of the access.  Be prepared to handle a
     type-mismatch here via creating a VIEW_CONVERT_EXPR.  */
  if (result
      && !useless_type_conversion_p (TREE_TYPE (result), TREE_TYPE (op)))
    {
      /* Avoid the type punning in case the result mode has padding where
         the op we lookup has not.  */
      if (maybe_lt (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (result))),
                    GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (op)))))
        result = NULL_TREE;

....


The result is BLKmode, op is V16QImode

Then reach
      /* Avoid the type punning in case the result mode has padding where
         the op we lookup has not.  */
      if (maybe_lt (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (result))),
                    GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (op)))))
        result = NULL_TREE;

If I delete this code, RVV can optimize it.

Do you have any suggestion ?

This is my observation:

Breakpoint 6, visit_reference_op_load (lhs=0x7ffff68364c8, op=0x7ffff6874410,
stmt=0x7ffff6872640) at ../../../../gcc/gcc/tree-ssa-sccvn.cc:5740
5740      result = vn_reference_lookup (op, vuse, default_vn_walk_kind, &res,
true, &last_vuse);
(gdb) c
Continuing.

Breakpoint 6, visit_reference_op_load (lhs=0x7ffff68364c8, op=0x7ffff6874410,
stmt=0x7ffff6872640) at ../../../../gcc/gcc/tree-ssa-sccvn.cc:5740
5740      result = vn_reference_lookup (op, vuse, default_vn_walk_kind, &res,
true, &last_vuse);
(gdb) n
5746          && !useless_type_conversion_p (TREE_TYPE (result), TREE_TYPE
(op)))
(gdb) p debug (result)
"\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
$9 = void
(gdb) p op->typed.type->type_common.mode
$10 = E_V16QImode

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
                 CC|                            |rguenth at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
  ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
  ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
  vect__1.7_10 = MEM <vector(16) char> [(char *)&ib];
  vect__2.10_34 = MEM <vector(16) char> [(char *)&ic];

so these.  The lookup result is a STRING_CST object.  I'm testing a patch.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

--- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #8)
>   ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
>   ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
>   vect__1.7_10 = MEM <vector(16) char> [(char *)&ib];
>   vect__2.10_34 = MEM <vector(16) char> [(char *)&ic];
> 
> so these.  The lookup result is a STRING_CST object.  I'm testing a patch.

I have compare and debug between ARM SVE and RVV.
It seems that ARM SVE produce result of visit_reference_op_load is
CONST_VECTOR:

(gdb) p debug(to)
{ 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 }
(gdb) p to->typed.type->type_common.mode
$23 = E_V16QImode

However, RVV produce result of visit_reference_op_load is STRING_CST:

(gdb) p debug (result)
"\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"

This is the BLKmode.

Could you tell me where I should fix in RISC-V backend?
It seems that it is not middle-end issue.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[rguenther at suse dot de]

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

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

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
> 
> --- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
> (In reply to Richard Biener from comment #8)
> >   ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> >   ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> >   vect__1.7_10 = MEM <vector(16) char> [(char *)&ib];
> >   vect__2.10_34 = MEM <vector(16) char> [(char *)&ic];
> > 
> > so these.  The lookup result is a STRING_CST object.  I'm testing a patch.
> 
> I have compare and debug between ARM SVE and RVV.
> It seems that ARM SVE produce result of visit_reference_op_load is
> CONST_VECTOR:
> 
> (gdb) p debug(to)
> { 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45 }
> (gdb) p to->typed.type->type_common.mode
> $23 = E_V16QImode
> 
> However, RVV produce result of visit_reference_op_load is STRING_CST:
> 
> (gdb) p debug (result)
> "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-"
> 
> This is the BLKmode.
> 
> Could you tell me where I should fix in RISC-V backend?
> It seems that it is not middle-end issue.

The IL into the SVE case is likely different.  The difference is
wheher we have a direct hashtable hit for the load or whether we
need to go through vn_reference_lookup_3 which will perform the
type punning on its own.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:7c76c876e917a1f20a788f602cc78fff7d0a2a65

commit r14-4527-g7c76c876e917a1f20a788f602cc78fff7d0a2a65
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Oct 10 11:09:16 2023 +0200

    Fix missed CSE with a BLKmode entity

    The following fixes fallout of r10-7145-g1dc00a8ec9aeba which made
    us cautionous about CSEing a load to an object that has padding bits.
    The added check also triggers for BLKmode entities like STRING_CSTs
    but by definition a BLKmode entity does not have padding bits.

            PR tree-optimization/111751
            * tree-ssa-sccvn.cc (visit_reference_op_load): Exempt
            BLKmode result from the padding bits check.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Should be fixed.  Feel free to add a RISC-V specific testcase so we don't
regress.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

--- Comment #13 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Thanks, Richi.

It does fix this issue.


This patch seems to cause an ICE in RISC-V:

#include <stdint-gcc.h>
#include <assert.h>

#define N 128

int
main ()
{
  uint8_t mask[N]
    = {0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
       0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
       0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
       0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
       0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
       0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1};
  uint8_t out[N] = {0};
  for (uint8_t i = 0; i < N; ++i)
    if (mask[i])
      out[i] = i;
  for (uint8_t i = 0; i < N; ++i)
    {
      if (mask[i])
        assert (out[i] == i);
      else
        assert (out[i] == 0);
    }
}

riscv64-unknown-elf-gcc --param riscv-autovec-preference=fixed-vlmax --param
riscv-autovec-lmul=m8 -O3 -S auto.c
during GIMPLE pass: fre
auto.c: In function 'main':
auto.c:7:1: internal compiler error: in execute_todo, at passes.cc:2137
    7 | main ()
      | ^~~~
0x1714290 execute_todo
        ../../../../gcc/gcc/passes.cc:2137

I guess this is caused by this following IR:

mask =
"\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01";
  out = "\x00";
  _51 = VIEW_CONVERT_EXPR<vector(128) unsigned
char>("\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01\x00\x01");
  mask__27.12_47 = _51 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0 };
  .MASK_LEN_STORE (&out, 8B, mask__27.12_47, 128, 0, { 0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87,
88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105,
106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121,
122, 123, 124, 125, 126, 127 });

There is a VIEW_CONVERT_EXPR here.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

--- Comment #14 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Also this case ICE:

typedef unsigned char __attribute__((vector_size(4))) uvec;

int main (int argc, char *argv[]) {
    int i;
    int x = 0;
    uvec uc0 = (uvec) {argc, 1,  2,  10};
    unsigned char uc1[4] = {0, 3, 2, 200};
    signed char ucg[4] = {1, 0, 0, 0 };
    signed char ucl[4] = {0, 1, 0, 1 };

#define uc0_ ((unsigned char *)&uc0)

    for (i = 0; i < 4; i ++) {
        x |= ucg[i] != (uc0_[i] > uc1[i]);
        x |= ucl[i] != (uc0_[i] < uc1[i]);
    }
    return x;
}

during GIMPLE pass: isel
dump file: auto.c.256t.isel
auto.c: In function 'main':
auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:328
    3 | int main (int argc, char *argv[]) {
      |     ^~~~
0x1bb55bd gimple_expand_vec_cond_expr
        ../../../../gcc/gcc/gimple-isel.cc:325
0x1bb57c6 execute
        ../../../../gcc/gcc/gimple-isel.cc:390


Looks odd, it ICE at gimple-isel.cc:

gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

--- Comment #15 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Also, I find this following case that ARM SVE failed to optimize:

https://godbolt.org/z/d6YnneETj

#define N 16

typedef int half_word;

int foo2 ()
{
  int i;
  half_word ia[N];
  half_word ic[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
  half_word ib[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};

  /* Not worthwhile, only 2 parts per int */
  for (i = 0; i < N; i++)
    {
      ia[i] = ib[i] + ic[i];
    }

  /* check results:  */
  for (i = 0; i < N; i++)
    {
      if (ia[i] != ib[i] + ic[i])
        abort ();
    }

  return 0;
}

I guess your approach can fix that for ARM SVE.  Maybe ARM SVE can also add
this case too.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #14)
> Also this case ICE:
> 
> typedef unsigned char __attribute__((vector_size(4))) uvec;
> 
> int main (int argc, char *argv[]) {
>     int i;
>     int x = 0;
>     uvec uc0 = (uvec) {argc, 1,  2,  10};
>     unsigned char uc1[4] = {0, 3, 2, 200};
>     signed char ucg[4] = {1, 0, 0, 0 };
>     signed char ucl[4] = {0, 1, 0, 1 };
> 
> #define uc0_ ((unsigned char *)&uc0)
> 
>     for (i = 0; i < 4; i ++) {
> 	x |= ucg[i] != (uc0_[i] > uc1[i]);
> 	x |= ucl[i] != (uc0_[i] < uc1[i]);
>     }
>     return x;
> }
> 
> during GIMPLE pass: isel
> dump file: auto.c.256t.isel
> auto.c: In function 'main':
> auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
> gimple-isel.cc:328
>     3 | int main (int argc, char *argv[]) {
>       |     ^~~~
> 0x1bb55bd gimple_expand_vec_cond_expr
>         ../../../../gcc/gcc/gimple-isel.cc:325
> 0x1bb57c6 execute
>         ../../../../gcc/gcc/gimple-isel.cc:390
> 
> 
> Looks odd, it ICE at gimple-isel.cc:
> 
> gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))

I have a fix for the first issue.  For this one the issue seems to be that
we do have vec_cmp for _2 > { 0, 3, 2, 200 } when doing instruction
selection for

mask__11.18_97 = VEC_COND_EXPR <mask__9.15_92, { 0, -1, -1, -1 }, { -1, 0, 0, 0
}>;

note the value is of vector boolean type.  But we fail to have
vcond_maskV4BIV4BI.

ISTR we have fixed sth similar
by adding missing patterns with VnBImode result?  But maybe forgot about
VLS modes here?

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 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:a704603d458b1e55b561ddfb4e513581ee863ed6

commit r14-4528-ga704603d458b1e55b561ddfb4e513581ee863ed6
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date:   Tue Oct 10 19:47:06 2023 +0800

    RISC-V: Add testcase for SCCVN optimization[PR111751]

    Add testcase for PR111751 which has been fixed:
    https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632474.html

            PR target/111751

    gcc/testsuite/ChangeLog:

            * gcc.target/riscv/rvv/autovec/pr111751.c: New test.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

--- Comment #18 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #16)
> (In reply to JuzheZhong from comment #14)
> > Also this case ICE:
> > 
> > typedef unsigned char __attribute__((vector_size(4))) uvec;
> > 
> > int main (int argc, char *argv[]) {
> >     int i;
> >     int x = 0;
> >     uvec uc0 = (uvec) {argc, 1,  2,  10};
> >     unsigned char uc1[4] = {0, 3, 2, 200};
> >     signed char ucg[4] = {1, 0, 0, 0 };
> >     signed char ucl[4] = {0, 1, 0, 1 };
> > 
> > #define uc0_ ((unsigned char *)&uc0)
> > 
> >     for (i = 0; i < 4; i ++) {
> > 	x |= ucg[i] != (uc0_[i] > uc1[i]);
> > 	x |= ucl[i] != (uc0_[i] < uc1[i]);
> >     }
> >     return x;
> > }
> > 
> > during GIMPLE pass: isel
> > dump file: auto.c.256t.isel
> > auto.c: In function 'main':
> > auto.c:3:5: internal compiler error: in gimple_expand_vec_cond_expr, at
> > gimple-isel.cc:328
> >     3 | int main (int argc, char *argv[]) {
> >       |     ^~~~
> > 0x1bb55bd gimple_expand_vec_cond_expr
> >         ../../../../gcc/gcc/gimple-isel.cc:325
> > 0x1bb57c6 execute
> >         ../../../../gcc/gcc/gimple-isel.cc:390
> > 
> > 
> > Looks odd, it ICE at gimple-isel.cc:
> > 
> > gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
> 
> I have a fix for the first issue.  For this one the issue seems to be that
> we do have vec_cmp for _2 > { 0, 3, 2, 200 } when doing instruction
> selection for
> 
> mask__11.18_97 = VEC_COND_EXPR <mask__9.15_92, { 0, -1, -1, -1 }, { -1, 0,
> 0, 0 }>;
> 
> note the value is of vector boolean type.  But we fail to have
> vcond_maskV4BIV4BI.
> 
> ISTR we have fixed sth similar
> by adding missing patterns with VnBImode result?  But maybe forgot about
> VLS modes here?

Confirm the second issue is fixed after I added vcond_mask of VLS BOOL mask
mode
I will commit it after I finish RISC-V regression.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:70b5c6981fcdff246f90e57e91f3e1667eab2eb3

commit r14-4537-g70b5c6981fcdff246f90e57e91f3e1667eab2eb3
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Oct 10 13:33:34 2023 +0200

    tree-optimization/111751 - support 1024 bit vector constant
reinterpretation

    The following ups the limit in fold_view_convert_expr to handle
    1024bit vectors as used by GCN and RVV.  It also robustifies
    the handling in visit_reference_op_load to properly give up when
    constants cannot be re-interpreted.

            PR tree-optimization/111751
            * fold-const.cc (fold_view_convert_expr): Up the buffer size
            to 128 bytes.
            * tree-ssa-sccvn.cc (visit_reference_op_load): Special case
            constants, giving up when re-interpretation to the target type
            fails.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 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:5255273ee8b14ea565eb43f067a86370d25df114

commit r14-4538-g5255273ee8b14ea565eb43f067a86370d25df114
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Date:   Tue Oct 10 20:15:35 2023 +0800

    RISC-V: Add VLS BOOL mode vcond_mask[PR111751]

    Richard patch resolve PR111751:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c76c876e917a1f20a788f602cc78fff7d0a2a65

    which cause ICE in RISC-V regression:

    FAIL: gcc.dg/torture/pr53144.c   -O2  (internal compiler error: in
gimple_expand_vec_cond_expr, at gimple-isel.cc:328)
    FAIL: gcc.dg/torture/pr53144.c   -O2  (test for excess errors)
    FAIL: gcc.dg/torture/pr53144.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error: in gimple_expand_vec_cond_expr,
at gimple-isel.cc:328)
    FAIL: gcc.dg/torture/pr53144.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
    FAIL: gcc.dg/torture/pr53144.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in
gimple_expand_vec_cond_expr, at gimple-isel.cc:328)
    FAIL: gcc.dg/torture/pr53144.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
    FAIL: gcc.dg/torture/pr53144.c   -O3 -g  (internal compiler error: in
gimple_expand_vec_cond_expr, at gimple-isel.cc:328)
    FAIL: gcc.dg/torture/pr53144.c   -O3 -g  (test for excess errors)

    VLS BOOL modes vcond_mask is needed to fix this regression ICE.

    More details: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751

    Tested and Committed.

            PR target/111751

    gcc/ChangeLog:

            * config/riscv/autovec.md: Add VLS BOOL modes.

[Bug tree-optimization/111751] RISC-V: RVV unexpected vectorization

[juzhe.zhong at rivai dot ai]

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

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

Finish and confirm RISC-V regression. 
All pass.

Thank you so much!