https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118269
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|rguenther at suse dot de |tnfchris at gcc dot
gnu.org
Priority|P3 |P1
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine then (and confirmed). It's odd we have only a single initial value but
two SLP lanes ... ah, this is a SLP reduction chain - for that the adjustment
def
should be OK.
But in vect_create_epilog_for_reduction we fail to classify it this way
because we look at REDUC_GROUP_FIRST_ELEMENT of the PHI info when called
via
if (LOOP_VINFO_EARLY_BREAKS (loop_vinfo))
{
slp_tree phis_node = slp_node ? slp_node_instance->reduc_phis : NULL;
for (auto exit : get_loop_exit_edges (LOOP_VINFO_LOOP (loop_vinfo)))
if (exit != LOOP_VINFO_IV_EXIT (loop_vinfo))
{
vect_create_epilog_for_reduction (loop_vinfo, reduc_info,
phis_node, slp_node_instance,
exit);
the issue is we do want to have the reduction PHI def values here, but I'm
not sure we support this case? Most definitely the !slp_reduc case
(reduction chain) with early breaks look broken, possibly not having
great coverage.
Possibly exposed by r14-9335-g89c443a7e9a078.
I have a fix.
