This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Implementing "restrict", and other alias questions


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]