https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125750
--- Comment #9 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Richard Biener from comment #8) > (In reply to Tamar Christina from comment #7) > > > > the part of the code that throws off SLP in both compilers is this > > > > int m0 = ((i < n) & (r[i] == 0)) ? -1 : 0; > > int m1 = ((i + 1 < n) & (r[i + 1] == 0)) ? -1 : 0; > > int m2 = ((i + 2 < n) & (r[i + 2] == 0)) ? -1 : 0; > > int m3 = ((i + 3 < n) & (r[i + 3] == 0)) ? -1 : 0; > > > > because m0 does `i < n` whereas the other operations have a +. > > > > semantically though we can make the SLP tree if we does > > > > int m0 = ((i + 0 < n) & (r[i + 0] == 0)) ? -1 : 0; > > int m1 = ((i + 1 < n) & (r[i + 1] == 0)) ? -1 : 0; > > int m2 = ((i + 2 < n) & (r[i + 2] == 0)) ? -1 : 0; > > int m3 = ((i + 3 < n) & (r[i + 3] == 0)) ? -1 : 0; > > > > which makes the SLP lanes match. Me and Richi talked about this two > > cauldrons > > ago and going SLP only was partially to try to do this in a way that doesn't > > require as much backtracking. > > I think there's another PR for that. My notes say that this should be > easier when re-doing the loop SLP discovery to be merge-based. But in > theory some special-cases can be hacked up in the current discovery, > possibly as part of the mangling we do with operand swapping > (it might also conflict with it, if you consider i < i + 1). yeah, I agree that merge-based is still the way to do, in particular in cases like the above we typically do have a lane > 1 tree as well. So in the above we do build the lane == 3 version. So perhaps the merge should start there, since that direct the only acceptable shape?
