https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rsand...@gcc.gnu.org from comment #7) > (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? Both - we'd pick up the wrong comparison code. OTOH looking at the vect_slp_rearrange_stmts code the only SLP nodes we actually have to re-arrange are leafs now that constants and invariants have their own SLP nodes. Which means we wouldn't touch COND_EXPR (or other) operation nodes at all. Of course that code has even less test coverage ... but I'll try to rework it this way.
