PATCH to implement `restrict' in C

[Nathan Sidwell]

Mark Mitchell & Richard Henderson wrote a discussion about `restrict'

It seems that the discussion's covered the area quite well and reached
agreement. I just though I'd add some comments from the `restrict'
proposer which confirm this.

A couple of years ago I did some work on restrict in a non-gnu context.
I'd played around with a much tighter restriction for C++, spelt if
`register' and placed it as a pointer qualifier. I had some discussion
with Bill Homer, the `restrict' proposer, when I was trying to get my
head round what `restrict' actually meant. I fell into the same trap as
Richard originally did. Here's a snippet of Bill's email,

Bill Homer wrote:
>A declaration of the form 
>
>    int * restrict p;
>
>says that the new alias "*p" gets an "exclusive license" for access
>to its associated object for each execution of its associated block.
>It can "sublicense" its access to another restricted pointer declared
>in a nested block or called function, or to any visible unrestricted
>pointer, and when the declaration goes out of scope, the access
>rights revert to any preexisting aliases.  So is the restriction on
>the object or on its aliases?  I guess it can be argued both ways.
>
>One practical advantage the current syntax has it that it allows us to
>introduce new versions of library function prototypes that are
>appropriately qualified but are still compatible with the previous
>prototypes, as in:
>
>  void memcpy(void * restrict s1, const void * restrict s2, size_t n);
[That was based in the c9x draft as it existed in March 1997, I don't
believe things have changed to invalidate the above.]

The important thing here is that although the restricted pointer is the
only pointer to the block at the declaration, it can immediately grant
that access to any other (non-restricted) pointer. (Restricted pointers
can only get it, if they're scoped in an inner block.) A data-flow
analysis is needed to solve the problem competely. Without such
analysis, the compiler must, of course, be pessimistic, as Mark's
implementation is.

Many thanks to Mark for implementing this.

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk