[LLVMdev] [cfe-dev] Clang devirtualization proposal (original) (raw)

Hal Finkel hfinkel at anl.gov
Sat Jul 25 18:00:12 PDT 2015

----- 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

More information about the llvm-dev mailing list