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

[Piotr Padlewski]

It can, but it will be UB, so we don't have to worry about it.

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