[LLVMdev] Missed devirtualization opportunities

[Nick Lewycky]

On 12 October 2010 05:00, Kenneth Uildriks <kennethuil at gmail.com> wrote:

> On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote:
> > 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.
>
> So does that mean that we're allowed to assume that, given an "old"
> pointer to that memory, the vtbl-ptr slot hasn't changed?


You're right, I hadn't thought this through. The whole point of making them
local is to say that "I'm sure these callees won't modify that memory"
regardless of what functions actually get called, even indirectly. We can't
know that they won't modify the vptr in advance, so invariant doesn't work
here. Making it non-local just means that we would need to know the static
call graph, which we don't because we haven't devirtualized yet so all the
calls are indirect.

Nick


>  Which
> allows us to devirtualize:
>
> Base* pT = GetMyObjectThatHappensToBeT();
> // ...
> // stuff that we can't tell what it does to our memory
> // ...
> pT->A();
> // more mysterious stuff
> pT->B();
> // etc.
>
> as long as we can tell that a given pointer is actually pT and not
> another pointer copied from it or aliased to it?
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101012/a28008e8/attachment.html>