Proposed resolution to aliasing issue.

[Mark Mitchell]

Giovanni Bajo wrote:
> Mark Mitchell <mark@codesourcery.com> wrote:
> 
> 
>>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".  */
>>   }
> 
> 
> It is not clear if you are speaking here of the C language or GENERIC, but
> anyway I'll comment.

C.

> Can the meaning of the attribute be reversed? I would like it to mark places
> where upcasts can happen.

In tandem with making the optimization off by default, yes, that would 
be OK.  The important thing is that we provide a mechanism to get the 
optimization, but that it is off by default.

> After all, there is absolutely no point in enabling it by default if, to make
> it useful, you have to decorate billions of function declarations.

You don't have to do that; you find the handful that matter in your 
program, and decorate those, just as people do now for functions that 
are pure, const, etc.

> - For the C and the C++ frontend, do not enable TBAA through -Ox, just keep it
> a separate option (-ftree-tbaa).

Picking nits:

Let's not call this type-based alias analysis.  We've already given a 
meaning for that term.  Sadly, I don't have a good suggestion.  Also, 
any switch with "tree" in it meant to be used by real users has probably 
been misnamed.  The tree-ness isn't relevant to users.

> - Add __attribute__((upcast)) that can be used to decorate pointers in
> parameter declarations which might be subject to upcasting during the
> function's body execution.

Picking more nits:

It's not just upcast, and so that's probably not the best name, but no 
matter; I take your meaning.

> - For C++ frontend, we can have a -fpod-upcast which adds attribute upcast
> automatically for all pointers to POD types.

> - Explain in the documentation that -ftree-tbaa is risky for C/C++ unless the
> code base is audited and __attribute__((upcast)) added wherever appropriate.

> - For the Java/Fortran/Ada frontend, probably TBAA can be on by default at -Ox,
> but I dunno.

I would be OK with this approach.

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