This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: vtable optimization (was Re: TREE_UNCHANGING?)
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Gabriel Dos Reis <gdr at codesourcery dot com>
- Cc: Jason Merrill <jason at redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: Fri, 10 May 2002 14:05:31 -0400 (EDT)
- Subject: Re: vtable optimization (was Re: TREE_UNCHANGING?)
On 10 May 2002, Gabriel Dos Reis wrote:
> Jason Merrill <jason@redhat.com> writes:
>
> | Another tangent: if we know the static type of the object, we can do even
> ^^^^^^^^^^^
>
> Hmm, did you mean "dynamic type"?
Yes, he must have meant "statically determine the dynamic type".
>
> | better: we can skip the vtable lookup entirely and call the function
> | directly. There is some simple code in the C++ frontend to handle this,
> | mostly in fixed_type_or_null; a more C++-aware optimizer could track the
> | static type information as well as the alias set, so that we could perform
> | this optimization for code like
> |
> | A a;
> | A *ap = &a;
> | ...
> | ap->f();
> |
> | as well as the simpler
> |
> | A a;
> | ...
> | a.f();
>
> That requires some kind of value propagation applyed to pointers.
> That is a valuable optimization to consider.
Correct.
In his specific case above, it only requires simple pointer analysis.
For the case of anything more, it requires class hierarchy analysis.
I.E.
void foo(A *ap)
{
ap->f();
}
requires more, including class hierarchy analysis.
However, if you combine inlining with it (so that foo is inlined into it's
caller), we're back to simple pointer analysis.
>
> | This stuff is probably better suited for an AST-level optimization pass.
>
> I completely agree with your observation.
>
> -- Gaby
>