Implementing "restrict", and other alias questions

John Carr jfc@tiac.net
Sat Dec 27 17:13:00 GMT 1997


A while ago I implemented a subset of the C9X "restrict" keyword for egcs.
It didn't go into 1.0, and I am now looking at it again and I want opinions.

0. Does anyone really care about restrict?

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).

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.

3. Are there any C++ constructs with useful aliasing properties?  The
latest snapshot should know that global non-placement operator new and
new[] return pointers to unique storage.  Is anything useful known about
"this" in constructors, destructors, or other member functions?

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?

5. Are there any important missing aliasing optimizations in Fortran?
(Moving stores out of loops doesn't count -- this is a loop optimizer
deficiency.)

6. Does anyone have any ideas for implementing type based aliasing?  The
current code only uses size of reference and doesn't even distinguish
pointers and integers (or int and long when they are the same size).  I'm
not primarily talking about the specific rules (but I would like to see a
good algorithm for applying the ANSI C or C++ aliasing rules given two GNU
C tree type structures).  I'm want ideas about implementation techniques.

In general the back end needs to be able to ask, is overlap between memory
accesses X and Y prohibited by type rules?  I thought about:

	A conflict matrix generated by the front end saying whether
	pseudo-registers A and B point to types which can overlap.

	Recording the types of pseudo-registers and having a callback
	to the front end to detect type based aliasing.

Note that pseudo-registers can be created by back end optimization passes
and it will be important to have proper aliasing information for some of
them.




More information about the Gcc mailing list