On Wed, 2005-05-04 at 16:24, Jeroen Dobbelaere wrote:
> I'm aware of that. The reason are asked for more clarity is that I
> think gcc should
> do better (as in the example I gave), but I want to be sure that this
> is still allowed
> by the standard.
Certainly gcc can and should do better, and this is allowed by the
standard, but implementing better support here is definitely
non-trivial.
> >From what I found on these pages I refered to, this could be made more
> >strict :
> accesses through restricted pointers would not interfere with other accesses,
> which would allow some more aggressive optimizations.
I took a look at the standard, and gcc seems to be in line with it. The
problem is that you can have something like
int sub (int * __restrict__ a) { int *b = a; ... }
and now a and b alias each other, even though one pointer was declared
restrict. If you can track these relationships, then this isn't a
problem. If you can't track these relationships, then you have to use
the semantics that gcc currently uses, which is only that different
restricted pointers don't alias each other. We can perhaps handle this
well in the tree-aliasing code (if it handled restrict at all), but it
would be difficult to handle this well in the RTL aliasing code.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
