Proposed resolution to aliasing issue.

[Mark Mitchell <mark at codesourcery dot com>]

Kenny and I had a long conversation about the aliasing issue, and 
reached the following proposed solution.

In short, the issue is, when given the following code:

  struct A {...};
  struct B { ...; struct A a; ...; };

  void f() {
    B b;
    g(&b.a);
  }

does the compiler have to assume that "g" may access the parts of "b" 
outside of "a".  If the compiler can see the body of "g" than it may be 
able to figure out that it can't access any other parts, or figure out 
which parts it can access, and in that case it can of course use that 
information.  The interesting case, therefore, is when the body of "g" 
is not available, or is insufficient to make a conclusive determination.

As Joseph said, this is an object of legitimate debate in the ISO C 
committee.  Nick's paper gives the various arguments repeated here by 
ourselves and others; it is clear that there is legitimate debate, and 
no obvious answer.  It's unclear what resolution will eventually be reached.

Our goals, therefore, are:

1. To avoid breaking code that may in fact already be conformant, or 
will be made explicitly conformant in some future revision of the standard.

2. To permit the compiler to make useful optimizations, given that in 
many cases the rest of "b" will not be modified by "g".

Our proposed approach is to -- by default -- assume that "g" may access 
all of "b".  However, in the event that the corresponding parameter to 
"g" has an attribute (name TBD, possibly the same as the one that 
appears in Danny's recent patch), then we may assume that "g" (and its 
callees) do not use the pointer to obtain access to any fields of "b".

For example:

  void g(A *p __attribute__((X)));

  void f() {
    B b;
    g(&b.a); /* Compiler may assume the rest of b is not accessed
                in "g".  */
  }

This approach allows users to annotate code to get better optimization 
while still perserving the behavior of current, possibly conforming, 
programs.

If, in future, the commitee reaches the conclusion that all functions 
should be treated as if they had the attribute, i.e., that you cannot 
perform the kinds of operations shown above in the example for "g", then 
we will modify the compiler so that, by default, the compiler treats all 
parameters as if they had this atrribute.  We would then also add a 
switch to disable the optimization for people who have legacy code, just 
as we have -fno-strict-aliasing.

[ I did not discuss this with Kenny, but another option is to have a 
-fassume-X switch, off by default, which treats your code as if you had 
the magic attribute everywhere. ]

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304