Mark Mitchell <[EMAIL PROTECTED]> 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.
Can the meaning of the attribute be reversed? I would like it to mark places
where upcasts can happen. In any code base you may pick up, there are probably
just a couple of points where you'd need to say "I'll upcast this pointer",
while *all* the other uses are ok as they are. So I guess it makes sense to
have the default *reversed*. Then, you can make TBAA disabled by default for
the C and C++ language.
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. And if it is
disabled by default, the meaning of the attribute can be reversed without any
risk. You can then state in the documentation how to use the attribute if one
really needs TBAA.
So to recap, my proposal is:
- For the C and the C++ frontend, do not enable TBAA through -Ox, just keep it
a separate option (-ftree-tbaa).
- 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.
- 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'm positive that for C++ there would be zero need for manual decoration in,
say, a whole OS distribution (Qt, KDE, Boost, and whatnot) if we use
"-ftree-tbaa -fpod-upcast".
Giovanni Bajo
