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

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


----- Original Message -----
> From: "Piotr Padlewski" <prazek at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Rafael EspĂ­ndola" <rafael.espindola at gmail.com>, "David Blaikie" <dblaikie at gmail.com>, "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:19:40 PM
> Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> 
> 
> It can, but it will be UB, so we don't have to worry about it.

Why is it UB? Or when it the placement new changing the vtable not UB?

 -Hal

> 
> 
> On Thu, Jul 16, 2015 at 10:16 AM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> ----- 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
> 
> 

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




More information about the cfe-dev mailing list