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.
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 [EMAIL PROTECTED] (916) 791-8304
