This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Implementing "restrict", and other alias questions
- To: jfc at tiac dot net
- Subject: Re: Implementing "restrict", and other alias questions
- From: Martin von Loewis <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Date: Sun, 28 Dec 1997 21:17:37 +0100
- CC: egcs at cygnus dot com
- References: <199712280112.UAA01060@jfc.>
> 0. Does anyone really care about restrict?
I see two major advantages in having restrict support in egcs:
- once it is available, large projects that rely on egcs will start
using it, in order to take advantage of the performance improvements
promised. In particular, I think that people will use it in Linux,
and perhaps in egcs itself.
- if implemented, egcs is on the way to C9X compliance
> 1. My first implementation, which I wrote based on documentation for Sun's
> compiler, only supports declaring function arguments "restrict". Would it
> still be useful with this limitation? Extending restrict to apply to all
> variable declarations would not be too hard, but getting the expected
> semantics might be. That is, the compiler could be made to accept but
> ignore restrict applied to non-parameter variables (this is legal; I am
> asking if is it good).
I think the keyword should be accepted in all places where the draft
allows for it. It will allow people to put it in places where they
think it belongs. The future will show what kinds of optimizations the
compiler can perform based on those declarations.
> 2. C9X restrict is a type qualifier like const or volatile. My
> implementation made restrict apply to a variable. So, for example,
> one can not declare typedef int * restrict restrict_pointer_to_int;
> or int * restrict * foo; but only int * restrict bar; Is this a
> serious limitation? It might be hard to change and the changes
> could cause more divergence of the gcc and egcs back end interfaces.
I think this would be a serious limitation, in the light of C9X
compliance. When I read the draft right
struct foo{
struct foo * restrict next;
int value;
};
Again, the implementation is free to ignore the declaration - it
should not reject it.
> 4. Should C++ support restrict too? If so, what language specific concerns
> are there? For example, can member functions be declared "restrict",
> causing the this pointer to be restrict-qualified?
I think the formal definition of restrict (6.5.3.1) gives a clue, as
well as the syntax. restrict can appear anywhere a type qualifier is
allowed (assuming the C++ grammar is similar to C :-). So allowing
restrict declarations for member functions might be reasonable.
Another issue is references: Is
void f(class C restrict &);
valid. If so, how does restrict interfere with function overloading?
Regards,
Martin