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.
