This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Hack to make restrict more useful


On 9/2/07, Paul Brook <paul@codesourcery.com> wrote:
> > > That said, second, my understanding of restrict, from reading the c99
> > > standard, is that it is perfectly valid for restrict pointers to alias
> > > each other during *loads*..  IE you can guarantee any restricted
> > > pointer that is stored into can't alias the other restricted pointers.
> > >  Those only used for loads can alias each other.
> >
> > How does it make a difference?  If for two pointers that are only
> > loaded from we say they don't alias I cannot imagine a transformation
> > that would get anything wrong.

Easy answer: Dependence testing and then loop transforms.

Given p[i] = a[i] + b[i], if you claim a and b can't alias, you will
now claim that a[i] and b[i] don't access the same memory on the same
iteration.

We could easily use this and some profit estimation to decide to say,
change the iteration space of a but not b,which will break since they
really do alias, and breaking this is bad because they are allowed to.

Again, I'd love to just ignore this and say "we don't care".
But we should not do it by saying "oh, well, this could never effect
anything".  It could.  You can come up with transformations that
break, and they all involve the compiler claiming a and b can't alias
when they can.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]