[LLVMdev] Missed devirtualization opportunities

John McCall rjmccall at apple.com
Mon Oct 11 21:10:49 PDT 2010


On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote:
> A better way for a front-end to declare that vtbl-ptr-hacking is not
> expected and not supported is for it to emit llvm.invariant.start and
> llvm.invariant.end calls for it.

Some of us were talking about this apropos your earlier post.
@llvm.invariant.start/end aren't appropriate, because the memory *isn't*
invariant;  the user is totally allowed to destruct the object in-place and
create a new object there.  The only thing the standard tells us is that
old references and pointers are only considered to be automatically
"forwarded" to the new object (i.e. aren't just invalid) if the types match.
So we're allowed to assume that a pointer or reference validly formed
to an object of dynamic type T will always refer to an object of that
dynamic type.

One possibility is to attach metadata to the object pointer somehow,
saying that it's to an object of a certain dynamic type;  it would then
be simple for a language-specific optimization to fold vtable loads
from such pointers into the appropriate vtable pointer, which would
in turn be subject to additional folding.  The chief obstacle here is
preventing other optimizations from merging two tagged pointers
in a way that leaves only one of the tags in place, which could break
semantics.  To handle this, we could introduce an opaque readnone
no-op intrinsic (@llvm.bless?) after constructor calls (its return value
being the result of the new-expression) and before destructor calls
(its return value becoming the dtor's 'this' pointer).  That, however,
has the disadvantage of interfering with memory optimizations
between the ctor, lifetime, and dtor;  but maybe those optimizations
could be taught to look through blessings.

(kudos to djg and sabre for the discussion earlier)

John.



More information about the llvm-dev mailing list