Alias Analysis

See GrokAliasing.

In the following example, your C compiler must assume that *x and *y might be the same variable:

 int munge (int *x, int *y) {
     int result = *x;
     *y = 10;	// might set *x, too.
     result = *x;
     return result;
 }
The compiler can't optimize away the second load through *x. It can optimise away the first!

Most C compilers assume that all pointers of a given type may be aliased. Many C compilers also assume that once you take the address of a variable, it might be pointed to by any pointer of the appropriate type.

Fortran compilers have much stricter rules. In the above example, it would be illegal for the programmer to pass in two identical pointers.


There is a new "noalias" keyword or some such in the new C standard. http://kbs.cs.tu-berlin.de/~jutta/c/noalias-88.html

Betcha didn't know that C was a happenin' language, huh?

No no no. There is no "no alias" in C; that proposal was ancient history. See NoAliasMustGoThisIsNotNegotiable? for the history.

You're probably thinking of C99 "restrict", by which the programmer guarantees that all accesses to the pointed-to item will be through the restricted pointer. Modifying the above example:

 int munge (int restrict *x, int restrict *y) {
     int result = *x;
     *y = 10;	    // guaranteed not to set *x
     result = *x;   // can be optimized away
     return result;
 }

But note that restrict does not solve 100% of all possible aliasing issues. For example, both x and y above might point to different locations in the same array.


Many C compilers for DigitalSignalProcessors treat "const" as a form of "restrict"; or can be told to do so as an optimization.


EditText of this page (last edited February 27, 2004) or FindPage with title or text search