https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to Richard Biener from comment #6) > (In reply to rsand...@gcc.gnu.org from comment #5) > > (In reply to Richard Biener from comment #3) > > > (In reply to Richard Biener from comment #2) > > > > when placing gcc_unreachable () at the swapping place and most testcases > > > > still pass when removing the IL operand swapping, only vect-cselim-1.c > > > > runfails (investigating). > > > > > > Ah, SLP ultimately fails here so the scalar IL is broken by the operation > > > code adjustment. In the end we should be able to avoid doing tree code > > > adjustments as well since we're swapping to make the code the same > > > as the first stmts code and we only ever look at the first scalar stmt > > > during SLP code-gen/analysis. > > > > Yeah, started wondering about that later too... > > So there's probably a single path where this is not true which is when we > go through vect_attempt_slp_rearrange_stmts thus when we have a SLPed > set of cond-reductions. I'm trying to come up with a testcase ... > > But I think the cure here should be to punt on vect_slp_rearrange_stmts, > do you agree? You know SLP much better than me :-) But yeah, that sounds good. Would we need to punt even for swap==1, or just swap==2?