[Bug c/110897] New: RISC-V: Fail to vectorize shift

[Bug c/110897] New: RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

            Bug ID: 110897
           Summary: RISC-V: Fail to vectorize shift
           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: ---

Since this commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=29370f1387274ad5a35a020db6a5d06c0324e6c1

causes RISCV a bunch of fails related to shift vectorization:
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5


When trying this simple case:
#define TEST1_TYPE(TYPE)                                        \
  __attribute__((noipa))                                        \
  void vshl_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)         \
  {                                                             \
    for (int i = 0; i < n; i++)                                 \
      dst[i] = a[i] << b[i];                                    \
  }

#define TEST2_TYPE(TYPE)                                        \
  __attribute__((noipa))                                        \
  void vshiftr_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)      \
  {                                                             \
    for (int i = 0; i < n; i++)                                 \
      dst[i] = a[i] >> b[i];                                    \
  }

#define TEST_ALL()      \
 TEST2_TYPE(uint16_t)   \


TEST_ALL()

rvv.c:23:1: missed: couldn't vectorize loop
rvv.c:23:1: missed: not vectorized: relevant stmt not supported: patt_29 = _4
>> patt_30;


It failed to vectorize.

Could you tell me how to adapt RISC-V port to make it vectorized ?

Thanks.

[Bug target/110897] RISC-V: Fail to vectorize shift

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does the riscv backend support uint32_t shifting? How about extending and
contracting to/from uint16_t to uint32_t?

[Bug target/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #2 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Yes, (In reply to Andrew Pinski from comment #1)
> Does the riscv backend support uint32_t shifting? How about extending and
> contracting to/from uint16_t to uint32_t?

Yes, RISC-V port support uint32_t shifting.

Try this code (I explictly add conversion ((uint32_t) a[i]) >> b[i]):


#include <stdint-gcc.h>

#define TEST2_TYPE(TYPE)                                        \
  __attribute__((noipa))                                        \
  void vshiftr_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)      \
  {                                                             \
    for (int i = 0; i < n; i++)                                 \
      dst[i] = ((uint32_t) a[i]) >> b[i];                                      
\
  }

#define TEST_ALL()      \
 TEST2_TYPE(uint16_t)   \

TEST_ALL()

.L4:
        vsetvli a5,a3,e8,mf4,ta,ma
        vle16.v v3,0(a1)
        vle16.v v2,0(a2)
        vsetivli        zero,4,e32,m1,ta,ma
        vzext.vf2       v1,v3
        vsetvli zero,zero,e16,mf2,ta,ma
        slli    a4,a5,1
        vnsrl.wv        v1,v1,v2
        sub     a3,a3,a5
        vsetvli zero,a5,e16,mf2,ta,ma
        vse16.v v1,0(a0)
        add     a1,a1,a4
        add     a2,a2,a4
        add     a0,a0,a4
        bne     a3,zero,.L4
        ret

It vectorize it successfully.
But I think compiler recognize it since LLVM can do the job:
https://godbolt.org/z/ecKjYco5b

LLVM doesn't need the explicit conversion codes still can vectorize it.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-08-04
             Target|riscv                       |riscv, x86_64-*-*
                 CC|                            |rsandifo at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
             Blocks|                            |53947
          Component|target                      |tree-optimization

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
it looks like you don't support vector short logical shift?  For some reason
vect_recog_over_widening_pattern doesn't check whether the demoted operation
is supported ...

The following helps on x86_64, it disables the demotion.  I think the idea
was that we eventually recognize a widening shift, so the narrow operation
itself doesn't need to be supported, but clearly that doesn't work out
when there is no such shift.

diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
index e4ab8c2d65b..4e4191652e3 100644
--- a/gcc/tree-vect-patterns.cc
+++ b/gcc/tree-vect-patterns.cc
@@ -3091,6 +3091,11 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
   if (!new_vectype || !op_vectype)
     return NULL;

+  optab optab;
+  if (!(optab = optab_for_tree_code (code, op_vectype, optab_vector))
+      || optab_handler (optab, TYPE_MODE (op_vectype)) == CODE_FOR_nothing)
+    return NULL;
+
   if (dump_enabled_p ())
     dump_printf_loc (MSG_NOTE, vect_location, "demoting %T to %T\n",
                     type, new_type);

with the patch above x86 can vectorize both loops with AVX2 but not without.

Can you confirm this helps on RISC-V as well?

Richard, what was the idea here?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #4 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #3)
> it looks like you don't support vector short logical shift?  For some reason
> vect_recog_over_widening_pattern doesn't check whether the demoted operation
> is supported ...
> 
> The following helps on x86_64, it disables the demotion.  I think the idea
> was that we eventually recognize a widening shift, so the narrow operation
> itself doesn't need to be supported, but clearly that doesn't work out
> when there is no such shift.
> 


Thanks Richi.


what is the "vector short logical shift" optab ?

Could you give me the optab name?

I am gonna try to support this in RISC-V port.


> diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> index e4ab8c2d65b..4e4191652e3 100644
> --- a/gcc/tree-vect-patterns.cc
> +++ b/gcc/tree-vect-patterns.cc
> @@ -3091,6 +3091,11 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
>    if (!new_vectype || !op_vectype)
>      return NULL;
>  
> +  optab optab;
> +  if (!(optab = optab_for_tree_code (code, op_vectype, optab_vector))
> +      || optab_handler (optab, TYPE_MODE (op_vectype)) == CODE_FOR_nothing)
> +    return NULL;
> +
>    if (dump_enabled_p ())
>      dump_printf_loc (MSG_NOTE, vect_location, "demoting %T to %T\n",
>                      type, new_type);
> 
> with the patch above x86 can vectorize both loops with AVX2 but not without.
> 
> Can you confirm this helps on RISC-V as well?
> 
> Richard, what was the idea here?

Yeah. I can try it after I try "vector short logical shift" pattern.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #3)
> it looks like you don't support vector short logical shift?  For some reason
> vect_recog_over_widening_pattern doesn't check whether the demoted operation
> is supported ...
> 
> The following helps on x86_64, it disables the demotion.  I think the idea
> was that we eventually recognize a widening shift, so the narrow operation
> itself doesn't need to be supported, but clearly that doesn't work out
> when there is no such shift.
> 
> diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> index e4ab8c2d65b..4e4191652e3 100644
> --- a/gcc/tree-vect-patterns.cc
> +++ b/gcc/tree-vect-patterns.cc
> @@ -3091,6 +3091,11 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
>    if (!new_vectype || !op_vectype)
>      return NULL;
>  
> +  optab optab;
> +  if (!(optab = optab_for_tree_code (code, op_vectype, optab_vector))
> +      || optab_handler (optab, TYPE_MODE (op_vectype)) == CODE_FOR_nothing)
> +    return NULL;
> +
>    if (dump_enabled_p ())
>      dump_printf_loc (MSG_NOTE, vect_location, "demoting %T to %T\n",
>                      type, new_type);
> 
> with the patch above x86 can vectorize both loops with AVX2 but not without.
> 
> Can you confirm this helps on RISC-V as well?
> 
> Richard, what was the idea here?

Hi, Richi.

I guess you mean "vector short logical shift" pattern is this:

(define_insn_and_split "v<optab><mode>3"
  [(set (match_operand:VI 0 "register_operand"  "=vr,vr")
    (any_shift:VI
     (match_operand:VI 1 "register_operand"     " vr,vr")
     (match_operand:VI 2 "vector_shift_operand" " vr,vk")))]
  "TARGET_VECTOR && can_create_pseudo_p ()"
  "#"
  "&& 1"
  [(const_int 0)]
{
  riscv_vector::emit_vlmax_insn (code_for_pred (<CODE>, <MODE>mode),
                                 riscv_vector::RVV_BINOP, operands);
  DONE;
}
 [(set_attr "type" "vshift")
  (set_attr "mode" "<MODE>")])

(define_code_iterator any_shift [ashift ashiftrt lshiftrt])

VI includes vector short.

I think RISCV port support vector short logical shift ?

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #6 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #3)
> it looks like you don't support vector short logical shift?  For some reason
> vect_recog_over_widening_pattern doesn't check whether the demoted operation
> is supported ...
> 
> The following helps on x86_64, it disables the demotion.  I think the idea
> was that we eventually recognize a widening shift, so the narrow operation
> itself doesn't need to be supported, but clearly that doesn't work out
> when there is no such shift.
> 
> diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> index e4ab8c2d65b..4e4191652e3 100644
> --- a/gcc/tree-vect-patterns.cc
> +++ b/gcc/tree-vect-patterns.cc
> @@ -3091,6 +3091,11 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
>    if (!new_vectype || !op_vectype)
>      return NULL;
>  
> +  optab optab;
> +  if (!(optab = optab_for_tree_code (code, op_vectype, optab_vector))
> +      || optab_handler (optab, TYPE_MODE (op_vectype)) == CODE_FOR_nothing)
> +    return NULL;
> +
>    if (dump_enabled_p ())
>      dump_printf_loc (MSG_NOTE, vect_location, "demoting %T to %T\n",
>                      type, new_type);
> 
> with the patch above x86 can vectorize both loops with AVX2 but not without.
> 
> Can you confirm this helps on RISC-V as well?
> 
> Richard, what was the idea here?

Hi, Richi.

I try this codes as you suggested:
  optab optab;
  if (!(optab = optab_for_tree_code (code, op_vectype, optab_vector))
      || optab_handler (optab, TYPE_MODE (op_vectype)) == CODE_FOR_nothing)
    return NULL;

[jzzhong@server1:/work/home/jzzhong/work/insn]$~/work/rvv-opensource/output/gcc-rv64/bin/riscv64-rivai-elf-gcc
-march=rv64gcv -O3 --param=riscv-autovec-preference=scalable -S
-fopt-info-vec-missed rvv.c
rvv.c:14:1: missed: couldn't vectorize loop
rvv.c:14:1: missed: not vectorized: no vectype for stmt: _4 = *_3;
 scalar_type: uint16_t


Still can not vectorize it.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #5)
> (In reply to Richard Biener from comment #3)
> > it looks like you don't support vector short logical shift?  For some reason
> > vect_recog_over_widening_pattern doesn't check whether the demoted operation
> > is supported ...
> > 
> > The following helps on x86_64, it disables the demotion.  I think the idea
> > was that we eventually recognize a widening shift, so the narrow operation
> > itself doesn't need to be supported, but clearly that doesn't work out
> > when there is no such shift.
> > 
> > diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> > index e4ab8c2d65b..4e4191652e3 100644
> > --- a/gcc/tree-vect-patterns.cc
> > +++ b/gcc/tree-vect-patterns.cc
> > @@ -3091,6 +3091,11 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
> >    if (!new_vectype || !op_vectype)
> >      return NULL;
> >  
> > +  optab optab;
> > +  if (!(optab = optab_for_tree_code (code, op_vectype, optab_vector))
> > +      || optab_handler (optab, TYPE_MODE (op_vectype)) == CODE_FOR_nothing)
> > +    return NULL;
> > +
> >    if (dump_enabled_p ())
> >      dump_printf_loc (MSG_NOTE, vect_location, "demoting %T to %T\n",
> >                      type, new_type);
> > 
> > with the patch above x86 can vectorize both loops with AVX2 but not without.
> > 
> > Can you confirm this helps on RISC-V as well?
> > 
> > Richard, what was the idea here?
> 
> Hi, Richi.
> 
> I guess you mean "vector short logical shift" pattern is this:
> 
> (define_insn_and_split "v<optab><mode>3"
>   [(set (match_operand:VI 0 "register_operand"  "=vr,vr")
>     (any_shift:VI
>      (match_operand:VI 1 "register_operand"     " vr,vr")
>      (match_operand:VI 2 "vector_shift_operand" " vr,vk")))]
>   "TARGET_VECTOR && can_create_pseudo_p ()"
>   "#"
>   "&& 1"
>   [(const_int 0)]
> {
>   riscv_vector::emit_vlmax_insn (code_for_pred (<CODE>, <MODE>mode),
> 				 riscv_vector::RVV_BINOP, operands);
>   DONE;
> }
>  [(set_attr "type" "vshift")
>   (set_attr "mode" "<MODE>")])
> 
> (define_code_iterator any_shift [ashift ashiftrt lshiftrt])
> 
> VI includes vector short.
> 
> I think RISCV port support vector short logical shift ?

The optab is vlshr_optab:

OPTAB_VC(vlshr_optab, "vlshr$a3", LSHIFTRT) 

your define_insn maybe produces the wrong names?

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #6)
> (In reply to Richard Biener from comment #3)
> > it looks like you don't support vector short logical shift?  For some reason
> > vect_recog_over_widening_pattern doesn't check whether the demoted operation
> > is supported ...
> > 
> > The following helps on x86_64, it disables the demotion.  I think the idea
> > was that we eventually recognize a widening shift, so the narrow operation
> > itself doesn't need to be supported, but clearly that doesn't work out
> > when there is no such shift.
> > 
> > diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> > index e4ab8c2d65b..4e4191652e3 100644
> > --- a/gcc/tree-vect-patterns.cc
> > +++ b/gcc/tree-vect-patterns.cc
> > @@ -3091,6 +3091,11 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
> >    if (!new_vectype || !op_vectype)
> >      return NULL;
> >  
> > +  optab optab;
> > +  if (!(optab = optab_for_tree_code (code, op_vectype, optab_vector))
> > +      || optab_handler (optab, TYPE_MODE (op_vectype)) == CODE_FOR_nothing)
> > +    return NULL;
> > +
> >    if (dump_enabled_p ())
> >      dump_printf_loc (MSG_NOTE, vect_location, "demoting %T to %T\n",
> >                      type, new_type);
> > 
> > with the patch above x86 can vectorize both loops with AVX2 but not without.
> > 
> > Can you confirm this helps on RISC-V as well?
> > 
> > Richard, what was the idea here?
> 
> Hi, Richi.
> 
> I try this codes as you suggested:
>   optab optab;
>   if (!(optab = optab_for_tree_code (code, op_vectype, optab_vector))
>       || optab_handler (optab, TYPE_MODE (op_vectype)) == CODE_FOR_nothing)
>     return NULL;
> 
> [jzzhong@server1:/work/home/jzzhong/work/insn]$~/work/rvv-opensource/output/
> gcc-rv64/bin/riscv64-rivai-elf-gcc -march=rv64gcv -O3
> --param=riscv-autovec-preference=scalable -S -fopt-info-vec-missed rvv.c
> rvv.c:14:1: missed: couldn't vectorize loop
> rvv.c:14:1: missed: not vectorized: no vectype for stmt: _4 = *_3;
>  scalar_type: uint16_t
> 
> 
> Still can not vectorize it.

Well, that means we do not have a vector mode for HImode elements?!

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #9 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
The name is correct, since the same pattern works for uint32 but fail to work
for uint16

I checked the build file:
CODE_FOR_vlshrrvvm1hi3 = 10350,


>> Well, that means we do not have a vector mode for HImode elements?!

We have vector mode for HImode. 

You can see CODE_FOR_vlshrrvvm1hi3, the "rvvm1hi" is vector HImode.

Consider this following case:

#define TEST2_TYPE(TYPE)                                        \
  __attribute__((noipa))                                        \
  void vshiftr_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)      \
  {                                                             \
    for (int i = 0; i < n; i++)                                 \
      dst[i] = (a[i]) >> b[i];                                  \
  }

#define TEST_ALL()      \
 TEST2_TYPE(uint32_t)   \
 TEST2_TYPE(uint16_t)   \

TEST_ALL()

rvv.c:15:1: missed: statement clobbers memory: vect__4.9_52 = .MASK_LEN_LOAD
(vectp_a.7_50, 32B, { -1, ... }, _65, 0);
rvv.c:15:1: missed: statement clobbers memory: vect__6.12_56 = .MASK_LEN_LOAD
(vectp_b.10_54, 32B, { -1, ... }, _65, 0);
rvv.c:15:1: missed: statement clobbers memory: .MASK_LEN_STORE
(vectp_dst.14_59, 32B, { -1, ... }, _65, 0, vect__8.13_57);

rvv.c:15:1: missed: couldn't vectorize loop
rvv.c:15:1: missed: not vectorized: no vectype for stmt: _4 = *_3;
 scalar_type: uint16_t


uint32_t can vectorize but uint16_t fail, we have defined both vector SImode
and
HImode for "vlshr$a3" optab.


I seems that we must support widen shift pattern in RISCV port even though we
don't  have widen shift instructions ?

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #9)
> I seems that we must support widen shift pattern in RISCV port even though
> we don't  have widen shift instructions ?
I doubt it.  Seems like one of those bugs where someone needs to walk through
what's happening in the code, rather than relying on the debug dumps.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #11 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I debug vectorizable_shift:


Breakpoint 1, vectorizable_shift (vinfo=0x3fb45d0, stmt_info=0x3fb5ea0,
gsi=0x0, vec_stmt=0x0, slp_node=0x0, cost_vec=0x7fffffffc648) at
../../../riscv-gcc/gcc/tree-vect-stmts.cc:6028
6028      scalar_dest = gimple_assign_lhs (stmt);
(gdb) n
6029      vectype_out = STMT_VINFO_VECTYPE (stmt_info);
(gdb) p scalar_dest->typed.type->type_common.mode
$7 = E_HImode
(gdb) call print_gimple_stmts(stdout,stmt,0,0)
No symbol "print_gimple_stmts" in current context.
(gdb) call print_gimple_stmt(stdout,stmt,0,0)
patt_33 = _4 >> patt_34;


It's odd here, we are supposed to vectorize this following codes in ifcvt dump:
  _5 = (int) _4;
  _8 = (int) _7;
  _9 = _5 >> _8;

You can see "_9 = _5 >> _8;". We should vectorize SImode instead of HImode.
The correct follow should be first extend HI -> SImode, Then vectorize logical
shift right for SImode, and finally truncate SImode to HImode.

Am I right? When I debug tree-vect-stmts.cc, the vectorization follow doesn't
work as we want ?

Thanks.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[rsandifo at gcc dot gnu.org]

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

--- Comment #12 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #11)
> You can see "_9 = _5 >> _8;". We should vectorize SImode instead of HImode.
> The correct follow should be first extend HI -> SImode, Then vectorize
> logical shift right for SImode, and finally truncate SImode to HImode.
The point of vect_recog_over_widening_pattern is to avoid the extension and
truncation.  So this is working as expected.  The question is why doing the
optimisation prevents vectorisation, given that the target apparently provides
HImode shifts right.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #13 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
I just checked ARM SVE has the same behavior with RISC-V:

https://godbolt.org/z/vY6ecY6Mx

You can see this compiler explorer. ARM trunk GCC SVE failed to vectorize it
too same as RISCV wheras ARM GCC 13.1 can vectorize it.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #14 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to rsandifo@gcc.gnu.org from comment #12)
> (In reply to JuzheZhong from comment #11)
> > You can see "_9 = _5 >> _8;". We should vectorize SImode instead of HImode.
> > The correct follow should be first extend HI -> SImode, Then vectorize
> > logical shift right for SImode, and finally truncate SImode to HImode.
> The point of vect_recog_over_widening_pattern is to avoid the extension and
> truncation.  So this is working as expected.  The question is why doing the
> optimisation prevents vectorisation, given that the target apparently
> provides HImode shifts right.

Oh, thanks Richard.

After deep analysis, I found this code make it failed:

      incompatible_op1_vectype_p
        = (op1_vectype == NULL_TREE
           || maybe_ne (TYPE_VECTOR_SUBPARTS (op1_vectype),
                        TYPE_VECTOR_SUBPARTS (vectype))
           || TYPE_MODE (op1_vectype) != TYPE_MODE (vectype));
      if (incompatible_op1_vectype_p
          && (!slp_node
              || SLP_TREE_DEF_TYPE (slp_op1) != vect_constant_def
              || slp_op1->refcnt != 1))
        {
          if (dump_enabled_p ())
            dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
                             "unusable type for last operand in"
                             " vector/vector shift/rotate.\n");
          return false;
        }

incompatible_op1_vectype_p is true.

The reason it becomes true is op1_vectype has the different NUNTIS with
vectype.

The reason why they are different NUNITS is because 

op1_vectype = get_vectype_for_scalar_type = RVVM1SImode.
vectype = STMT_VINFO_VECTYPE (stmt_info) = RVVMF2SImode.

That's the reason why they are different make it failed.

As for easier understand for ARM SVE, I believe ARM sve:

op1_vectype = get_vectype_for_scalar_type = VNx4SImode.
vectype = STMT_VINFO_VECTYPE (stmt_info) = VNx2SImode.

Then ARM SVE also failed.

When revert that commit, they are the same (both are RVVM1SImode for RISCV
or VNx4SImode for ARM SVE).

Could you tell me how to fix that ? 

Thanks.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, the question is why we arrive here with the two different vector types.
Can you tell me a relevant cc1 compiler command like for a x86->riscv cross
that exposes the issue?

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #16 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #15)
> Well, the question is why we arrive here with the two different vector types.
> Can you tell me a relevant cc1 compiler command like for a x86->riscv cross
> that exposes the issue?

Thanks for taking care of this issue.

The RISC-V cc1 command:

cc1 -march=rv64gcv -mabi=lp64d --param=riscv-autovec-preference=scalable

For ARM SVE:

-march=armv8-a+sve -O3

This issue is exposed in both RISC-V and ARM.

code:

#include <stdint-gcc.h>

#define TEST2_TYPE(TYPE)                                        \
  __attribute__((noipa))                                        \
  void vshiftr_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)      \
  {                                                             \
    for (int i = 0; i < n; i++)                                 \
      dst[i] = (a[i]) >> b[i];                                  \
  }

#define TEST_ALL()      \
 TEST2_TYPE(uint16_t)   \

TEST_ALL()

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #17 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Confirm by this try:
https://godbolt.org/z/q7zx5zG5e

Both ARM SVE trunk GCC and RISC-V GCC failed to vectorize simple
unsigned short shift right, with following failed information:

<source>:14:1: missed: couldn't vectorize loop
<source>:14:1: missed: not vectorized: relevant stmt not supported: patt_47 =
MIN_EXPR <_7, 15>;
Compiler returned: 0

This following code can fix it:

index 2cedf2384..cda27fed9 100644
--- a/riscv-gcc/gcc/tree-vect-patterns.cc
+++ b/riscv-gcc/gcc/tree-vect-patterns.cc
@@ -3133,7 +3133,8 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
                return NULL;
            }
          else
-           append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt);
+           append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt,
+                                   op_vectype);
          ops[1] = new_var;
        }
     }


Bootstrap and Regression in progress, Ok for trunk ?

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

--- Comment #18 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to JuzheZhong from comment #17)
> Confirm by this try:
> https://godbolt.org/z/q7zx5zG5e
> 
> Both ARM SVE trunk GCC and RISC-V GCC failed to vectorize simple
> unsigned short shift right, with following failed information:
> 
> <source>:14:1: missed: couldn't vectorize loop
> <source>:14:1: missed: not vectorized: relevant stmt not supported: patt_47
> = MIN_EXPR <_7, 15>;
> Compiler returned: 0
> 
> This following code can fix it:
> 
> index 2cedf2384..cda27fed9 100644
> --- a/riscv-gcc/gcc/tree-vect-patterns.cc
> +++ b/riscv-gcc/gcc/tree-vect-patterns.cc
> @@ -3133,7 +3133,8 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
>                 return NULL;
>             }
>           else
> -           append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt);
> +           append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt,
> +                                   op_vectype);
>           ops[1] = new_var;
>         }
>      }
> 
> 
> Bootstrap and Regression in progress, Ok for trunk ?

Bootstrap and regression on X86 passed.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to JuzheZhong from comment #18)
> (In reply to JuzheZhong from comment #17)
> > Confirm by this try:
> > https://godbolt.org/z/q7zx5zG5e
> > 
> > Both ARM SVE trunk GCC and RISC-V GCC failed to vectorize simple
> > unsigned short shift right, with following failed information:
> > 
> > <source>:14:1: missed: couldn't vectorize loop
> > <source>:14:1: missed: not vectorized: relevant stmt not supported: patt_47
> > = MIN_EXPR <_7, 15>;
> > Compiler returned: 0
> > 
> > This following code can fix it:
> > 
> > index 2cedf2384..cda27fed9 100644
> > --- a/riscv-gcc/gcc/tree-vect-patterns.cc
> > +++ b/riscv-gcc/gcc/tree-vect-patterns.cc
> > @@ -3133,7 +3133,8 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
> >                 return NULL;
> >             }
> >           else
> > -           append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt);
> > +           append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt,
> > +                                   op_vectype);
> >           ops[1] = new_var;
> >         }
> >      }
> > 
> > 
> > Bootstrap and Regression in progress, Ok for trunk ?
> 
> Bootstrap and regression on X86 passed.

We generally want to avoid setting a vector type during pattern recog esp.
for BB vectorization.  It will tie later analysis hands.  Why does the
later analysis not figure out the "proper" vector type?  Oh.  We force
it to the vector type of the final pattern stmt ... (not sure why we
do this ...).

The patch is OK, sorry for missing this.

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai]

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

JuzheZhong <juzhe.zhong at rivai dot ai> changed:

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

--- Comment #20 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Fixed by this patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c5f673dbc252e35e6b66e9b8abd30a4027193e0b