https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85720
--- Comment #6 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) > (In reply to Mathias Stearn from comment #4) > > (In reply to Marc Glisse from comment #3) > > > Again, you are ignoring aliasing issues (just like in your other PR the > > > function copy isn't equivalent to memmove). Does adding __restrict change > > > the result? Also, B[i]=B[i]+1 doesn't look like a memset... > > > > Sorry, I typoed. It was supposed to be B[i] = A[i] + 1. That still does > > basically the same thing though: https://godbolt.org/g/dtmU5t. Good point > > about aliasing though. I guess the right code gen in that case would > > actually be something that detected the overlap and did the right calls to > > memset to only set each byte once. Or just do the simple thing: > > > > if (b > a && b < a + n) { > > memset(b, 1, n); > > memset(a, 0, n); > > } else { > > memset(a, 0, n); > > memset(b, 1, n); > > } > > > > Yes, __restrict helps, but that isn't part of standard c++, and it seems > > like it never will be. > > GCC supports it since forever... but yes, currently loop distribution > doesn't consider runtime aliasing in this case (it can do it now but This should be easy to improve for builtin distribution cases. > is keyed to vectorization). It also doesn't have a way to distinguish > forward vs. backward dependence and split the case like you propose. IMHO, this isn't optimizer's responsibility. If break-conditions for forward/backward dependence need to be supported, it seems more reasonable to be supported in dependence analysis.
