[LLVMdev] [cfe-dev] Clang devirtualization proposal

[Hal Finkel]

----- Original Message -----
> From: "Richard Smith" <richard at metafoo.co.uk>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Piotr Padlewski" <prazek at google.com>, "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>,
> "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Saturday, July 25, 2015 7:43:37 PM
> Subject: Re: [cfe-dev] Clang devirtualization proposal
> 
> 
> 
> 
> On Sat, Jul 25, 2015 at 12:39 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> Hi Piotr,
> 
> Thanks for posting this! First, a question. When you say, regarding
> i8* @llvm.invariant.group.barrier(i8*):
> 
> "Required to handle destructors, placement new and std::launder. Call
> of this function will be put on the end of each of this functions"
> 
> I completely understand placement new and std::launder. I don't
> understand destructors, could you explain?
> 
> When a derived class destructor invokes a base class destructor, the
> dynamic type of the object changes (as does the vptr), so we need an
> invariant barrier to prevent the derived class's vptr being used for
> virtual calls in an inlined base class destructor.

Interesting. So we'll launder the 'this' pointer through @llvm.invariant.group.barrier before changing the vptr and calling the base class destructor?

> 
> 
> Also, am I correct in saying that we could handle the case of 'final'
> classes I highlighted in initial e-mail by inserting these
> assumptions whenever a pointer/reference to a class of such a type
> came into scope?
> 
> 
> 
> Yes, it would be correct to insert these assumptions anywhere where
> the language standard guarantees that there exists an object of a
> known (most-derived) dynamic type (and in particular, we can do this
> whenever we know there exists an object of a known final type).
> 
> 
> CodeGen already invokes EmitTypeCheck in many of the places where
> it's guaranteed that an object of a known type exists; we could
> experiment with adding an assumption from it any time that type is
> final.

Sounds good.
 
> 
> struct A {
> virtual void foo() = 0;
> };
> 
> struct B final : public A {
> void foo();
> };
> 
> void entry(B *b) {
> // emit assumptions about vtbl of 'b' here?
> 
> 
> This case is tricky. We don't currently have a way of saying "assume
> that a load of %b would load %B.vtbl" without also saying "assume
> that %b is dereferenceable". We've seen other cases where that would
> be beneficial, so perhaps that's something we should consider
> adding.

Ah, good point. We could only do it for references currently. I think adding something in this direction makes sense, something that says, perhaps, "we don't know if %b is deferenceable, but if it is, and you were to load from it, you'd get the following."

Thanks again,
Hal

> 
> 
> }
> 
> Thanks again,
> Hal
> 
> ----- Original Message -----
> > From: "Piotr Padlewski" < prazek at google.com >
> > To: " cfe-dev at cs.uiuc.edu Developers" < cfe-dev at cs.uiuc.edu >,
> > llvmdev at cs.uiuc.edu
> > Cc: "Richard Smith" < richard at metafoo.co.uk >
> > Sent: Wednesday, July 22, 2015 4:55:43 PM
> > Subject: [cfe-dev] Clang devirtualization proposal
> > 
> > 
> > 
> > 
> > Hi folks,
> > this summer I will work with Richard Smith on clang
> > devirtualization.
> > Check out our proposal:
> > 
> > https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing
> > 
> > 
> > 
> > And modified LangRef
> > http://reviews.llvm.org/D11399
> > 
> > 
> > 
> > You can also check out previous disscussion that was started before
> > our proposal was ready -
> > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-July/044052.html
> > 
> > 
> > Regards
> > Piotr Padlewski
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > 
> 
> 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory