[Bug tree-optimization/125567] SLP build misses operand swapping for a commutative scalar-vector add pattern

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125567

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 2 Jun 2026, chenzhongyao.hit at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125567
> 
> --- Comment #2 from Zhongyao Chen <chenzhongyao.hit at gmail dot com> ---
> current swap logic is guarded by `!vect_def_types_match (oprnd_info->first_dt,
> dt)` in vect_get_and_check_slp_defs.
> 
> in this testcase, _7 and tmp.1_8 are both internal type, so didn't triger swap.
> 
> maybe we can add a small heuristic here:
> even if the types match, if swapping the current lane makes one operand line up
> exactly with the same operand column of the first lane, then we still swap.
> 
> Here, after swapping, `tmp.1_8` lines up exactly with the same operand column
> as in the first lane.  Of course, that does not have to be the only rule, we
> can extend it later.

The swapping in vect_build_slp_tree_2 should have covered this case:

      /* If the SLP build for operand zero failed and operand zero
         and one can be commuted try that for the scalar stmts
         that failed the match.  */
      if (i == 0
          /* A first scalar stmt mismatch signals a fatal mismatch.  */
          && matches[0]

but it might be that if, for BB vect, operand zero was SLP discvered
as external, operand one discovery could be still fixed by operand
swapping.  Is that the case here?  It's going to be a bit awkward
to handle this here, but basically we might want to avoid building
an operand from scalars (aka external) upon failure when upstream
could still perform operand swapping.