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/3/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> 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_?

You may be right, but it just means we have to be very careful where
we use the data if there are no modifications.
I'm not sure the best way to go about this.  Right now, i attached
restrict info to SSA_NAME's, and we use it in
access_can_touch_variable, may_alias_p, and the dataref version of
this.

Sadly though, it also means we can't use restricted pointers to say
anything about non-restricted pointers unless their is modification
either.

IE int foo(int *a, restrict *b), doesn't guarantee a and b don't alias
unless there is a modification of one of them.
--Dan


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