[Bug tree-optimization/85720] bad codegen for looped assignment of primitives at -O2

amker at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue May 15 15:20:00 GMT 2018


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.


More information about the Gcc-bugs mailing list