Re: PATCH to implement `restrict' in C

[Jeffrey A Law <law at cygnus dot com>]

  > > Partly, I think that your intuition about the common case may be off.
  > 
  > You are probably right there.
I'll interject a thought or two on the "common case" question :-)

I recently returned from a visit with a Cygnus customer where issues of this
nature came up.

Basically, this company passes lots of small arrays around by reference and
has relatively simple routines to operate on them.  ie

typedef int vector[8];

blah (vector a, vector b, vector result)
{
  for (i = 0; i < 8; i++)
    result[i] = a[i] OP b[i];
}


They do this kind of stuff *a lot* (slightly more complicated, but you get the
idea).  And in every case they always know A & B will not refer to the same
memory.

In the end, the semantics they want for these functions are Fortran aliasing.
In fact, we used -fargument-noalias to get a feel for how the generated code
would change if we had a mechanism to indicate that these arguments don't
alias each other.

Just a real world tidbit.

When y'all reach an agreement about what restrict means, let me know :-)

I've also cc'd John Carr who had some interest in "restrict" a while back, he
may have further comments on the implementation (John -- see the egcs-patches
archive for the actual patch).

  > With some more reflection I see why you have chosen to approach
  > things the way you have.  We do not currently have the tools to
  > approach the data flow problem while retaining sanity, and your
  > scheme will work with or without such analysis.
So, from the language correctness standpoint, are we OK with this
implementation?

jeff