Hi, Kewin.
Could you test 'can_vec_extract_var_idx_p' and send V5 patch when you pass the
testing?
Thanks.
juzhe.zh...@rivai.ai
From: Kewen.Lin
Date: 2023-08-14 17:19
To: Robin Dapp
CC: gcc-patches; richard.sandiford; rguenther; juzhe.zh...@rivai.ai
Subject: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST
vectorization
Hi Robin,
on 2023/8/14 16:58, Robin Dapp wrote:
> Hi Kewen,
>
>> I did a bootstrapping and regression testing on Power10 (LE) and found a lot
>> of failures.
>
> I think the problem is that just like for vec_set we're expecting
> the vec_extract expander not to fail. It is probably passed not a
> const int here anymore and therefore fails to expand?
Thanks for the comments! Yeah, I think the expectation doesn't hold
on Power, as our vec_extract optab only support const index, that
is:
(define_expand "vec_extract<mode><VEC_base_l>"
[(match_operand:<VEC_base> 0 "register_operand")
(match_operand:VEC_E 1 "vlogical_operand")
(match_operand 2 "const_int_operand")]
"VECTOR_MEM_ALTIVEC_OR_VSX_P (<MODE>mode)"
{
rs6000_expand_vector_extract (operands[0], operands[1], operands[2]);
DONE;
})
>
> can_vec_extract_var_idx_p is supposed to check if the backend
> supports extracting a variable index.
OK, it sounds that this new capability needs to further check with
function can_vec_extract_var_idx_p to ensure the ifn expanding work
as expected. I re-spined by adding the below as your comments:
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 07f3717ed9d..80ba5cae84a 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -10328,7 +10328,9 @@ vectorizable_live_operation (vec_info *vinfo,
stmt_vec_info stmt_info,
else if (convert_optab_handler (vec_extract_optab,
TYPE_MODE (vectype),
TYPE_MODE (TREE_TYPE (vectype)))
- != CODE_FOR_nothing)
+ != CODE_FOR_nothing
+ && can_vec_extract_var_idx_p (
+ TYPE_MODE (vectype), TYPE_MODE (TREE_TYPE (vectype))))
vect_record_loop_len (loop_vinfo,
&LOOP_VINFO_LENS (loop_vinfo),
1, vectype, 1);
BR,
Kewen
