On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 9/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > > On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > On 9/2/07, Paul Brook <[EMAIL PROTECTED]> 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.
I think this should be ok. > 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. Well, that is probably to make handling of contrieved "derivations" of a restrict pointer conservatively correct. That is, for example restrict int *p; int pi = (int)p; *(int *)p = 1; just assuming that there are derivations that PTA cannot deal with. The way the standard is written it's just for a safe default. Richard.
