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.

Reply via email to