[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 JuzheZhong changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from JuzheZhong --- Fixed by this patch: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c5f673dbc252e35e6b66e9b8abd30a4027193e0b
[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #19 from Richard Biener --- (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: > > > > :14:1: missed: couldn't vectorize loop > > :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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #18 from JuzheZhong --- (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: > > :14:1: missed: couldn't vectorize loop > :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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #17 from JuzheZhong --- 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: :14:1: missed: couldn't vectorize loop :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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #16 from JuzheZhong ---
(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
#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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #15 from Richard Biener --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #14 from JuzheZhong ---
(In reply to rsand...@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #13 from JuzheZhong --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #12 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #11 from JuzheZhong --- I debug vectorizable_shift: Breakpoint 1, vectorizable_shift (vinfo=0x3fb45d0, stmt_info=0x3fb5ea0, gsi=0x0, vec_stmt=0x0, slp_node=0x0, cost_vec=0x7fffc648) 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #10 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #9 from JuzheZhong ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #8 from Richard Biener --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #7 from Richard Biener ---
(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 "v3"
> [(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 (, mode),
>riscv_vector::RVV_BINOP, operands);
> DONE;
> }
> [(set_attr "type" "vshift")
> (set_attr "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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #6 from JuzheZhong --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #5 from JuzheZhong ---
(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 "v3"
[(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 (, mode),
riscv_vector::RVV_BINOP, operands);
DONE;
}
[(set_attr "type" "vshift")
(set_attr "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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 --- Comment #4 from JuzheZhong --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897 Richard Biener 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 --- 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
