https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114231
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the immediate reason is that between analysis and transform whether we
consider the shift vectorizable changes. That's because we code generated
a live lane which ended up changing operands in stmts we will vectorize
(there's some odd broken handling there I think). That's because we
match up the scalar from the SLP node with the scalar in the scalar GIMPLE
IL (which changed) here:
stmt_vec_info op1_def_stmt_info;
slp_tree slp_op1;
if (!vect_is_simple_use (vinfo, stmt_info, slp_node, 1, &op1, &slp_op1,
&dt[1], &op1_vectype, &op1_def_stmt_info))
...
FOR_EACH_VEC_ELT (stmts, k, slpstmt_info)
{
gassign *slpstmt = as_a <gassign *> (slpstmt_info->stmt);
if (!operand_equal_p (gimple_assign_rhs2 (slpstmt), op1, 0))
scalar_shift_arg = false;
}
which is a bit fragile.
But the underlying issue seems to be the live lane stuff.
Ah, and that's because we do the reduction discovery on the original
scalar stmt while live lane extraction honors patterns when checking
whether the stmt is vectorized ...
I have a patch, not sure how big the fallout might be though.
