This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Hack to make restrict more useful
On 9/3/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> 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.
Eh? Maybe I'm blind, but how can a change in iteration space that is
valid for the non-aliasing case be invalid for the aliasing case _if we
do not modify any data_?
Ok, Marks example is the only one we could get wrong. But we simply
can not derive value ranges from restrict qualification.
Richard.