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 ?
