[cfe-dev] C++11 and enhacned devirtualization

Hal Finkel hfinkel at anl.gov
Thu Jul 16 10:16:30 PDT 2015


----- Original Message -----
> From: "Rafael EspĂ­ndola" <rafael.espindola at gmail.com>
> To: "Piotr Padlewski" <prazek at google.com>
> Cc: "David Blaikie" <dblaikie at gmail.com>, "Hal Finkel" <hfinkel at anl.gov>, "Richard Smith" <richard at metafoo.co.uk>,
> "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Sent: Thursday, July 16, 2015 12:14:29 PM
> Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> 
> On 16 July 2015 at 10:02, Piotr Padlewski <prazek at google.com> wrote:
> > The proposal of our solution will be published next week. Brief
> > introduction:
> >
> > "Basic idea is to mark vtable loads with !invariant , and also put
> > assume()
> > after calling constructor to show how vtable will look like.
> > Function
> > @llvm.invariant.barrier that breaks the invariant will be needed to
> > cope
> > with placement new and other cases where the vptr is legitimately
> > permitted
> > to change."
> 
> 
> Nice, this should also avoid loading the vtable pointer multiple
> times in
> 
> struct C {
>   virtual void foo();
> };
> void g();
> void f(C *x) {
>   x->foo();
>   g();

Not if g() might placement-new something else on top of x. The problem is that if we need to make conservative assumptions about whether or not g() might contain a '@llvm.invariant.barrier', we must assume it might.

 -Hal

>   x->foo();
> }
> 
> Cheers,
> Rafael
> 

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




More information about the cfe-dev mailing list