https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85720
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
CC| |amker at gcc dot gnu.org
Component|middle-end |tree-optimization
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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
is keyed to vectorization). It also doesn't have a way to distinguish
forward vs. backward dependence and split the case like you propose.
