Douglas Gregor wrote:
> The type of the expression could be a record type even if the dynamic
> type of the object isn't known at compile time. If I tweak your
> example like this:
>
> void f(A &a) {
> a.f('c');
> }
>
> I now get a direct call, when I should get a virtual call. To do this
> devirtualization, I suggest abstracting the "find the dynamic type of
> this expression" logic into a separate function. Then, we can teach it
> about common cases, such as referring to a VarDecl of (non-reference)
> type, constructing a temporary of a specific type, etc. I expect that
> this logic will get smarter over time, as we think of more analyses
> that can help make this distinction.
>
Devirtualization is something we should somehow make LLVM do, when we do
other optimizations. For example, take your 'f' above and do this:
void g() {
A a;
f(a);
}
If LLVM decides to inline the call to f here, the type of the call to
A::f becomes statically known in the inlined version, and the call
should be direct.
Sebastian
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
