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