[cfe-dev] Clang devirtualization proposal

Richard Smith richard at metafoo.co.uk
Sat Jul 25 17:43:37 PDT 2015


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.


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

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.


> }
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150725/0a625c8a/attachment.html>


More information about the cfe-dev mailing list