https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107082
Bug ID: 107082
Summary: Fix incorrect handle in vectorizable_induction for
mixed induction type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
The codes in vectorizable_induction for slp_node assume all phi_info
have same induction type(vect_step_op_add), but since we support
nonlinear induction, it could be wrong handled.
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601913.html
----------Comments from Richard-------
While it works to check this here the canonical place to match up def
types is in
vect_get_and_check_slp_defs. There we do
/* Not first stmt of the group, check that the def-stmt/s match
the def-stmt/s of the first stmt. Allow different definition
types for reduction chains: the first stmt must be a
vect_reduction_def (a phi node), and the rest
end in the reduction chain. */
if ((!vect_def_types_match (oprnd_info->first_dt, dt)
&& !(oprnd_info->first_dt == vect_reduction_def
&& !STMT_VINFO_DATA_REF (stmt_info)
the induction def type match now needs to also compare
STMT_VINFO_LOOP_PHI_EVOLUTION_TYPE
it seems.
Note we also fail to do this for STMT_VINFO_REDUC_TYPE (but that's eventually
only computed too late).
Being able to reject this during SLP discovery means that if you'd have
x = i + j;
y = j + i;
with two different induction types for 'i' and 'j', SLP discovery can
try commutative
swapping to match the inductions up for x and y and successfully SLP
the operation.
That said, I can see the checking condition becoming more ugly (please don't
try to amend vect_def_types_match itself), adding something like
|| (oprnd_info->first_dt == vect_induction_def
&& STMT_VINFO_LOOP_PHI_EVOLUTION_TYPE (...) != ... (stmts[0]))
Can you try doing that?
-----comments end--------
Open this PR to track this.
