<div dir="ltr">It can, but it will be UB, so we don't have to worry about it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 10:16 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Rafael Espíndola" <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>><br>
</span><span class="">> To: "Piotr Padlewski" <<a href="mailto:prazek@google.com">prazek@google.com</a>><br>
> Cc: "David Blaikie" <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>>, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>, "Richard Smith" <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>,<br>
> "<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> Developers" <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>
</span><span class="">> Sent: Thursday, July 16, 2015 12:14:29 PM<br>
> Subject: Re: [cfe-dev] C++11 and enhacned devirtualization<br>
><br>
</span><span class="">> On 16 July 2015 at 10:02, Piotr Padlewski <<a href="mailto:prazek@google.com">prazek@google.com</a>> wrote:<br>
> > The proposal of our solution will be published next week. Brief<br>
> > introduction:<br>
> ><br>
> > "Basic idea is to mark vtable loads with !invariant , and also put<br>
> > assume()<br>
> > after calling constructor to show how vtable will look like.<br>
> > Function<br>
> > @llvm.invariant.barrier that breaks the invariant will be needed to<br>
> > cope<br>
> > with placement new and other cases where the vptr is legitimately<br>
> > permitted<br>
> > to change."<br>
><br>
><br>
> Nice, this should also avoid loading the vtable pointer multiple<br>
> times in<br>
><br>
> struct C {<br>
>   virtual void foo();<br>
> };<br>
> void g();<br>
> void f(C *x) {<br>
>   x->foo();<br>
>   g();<br>
<br>
</span>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.<br>
<br>
 -Hal<br>
<br>
>   x->foo();<br>
> }<br>
><br>
> Cheers,<br>
> Rafael<br>
<div class="HOEnZb"><div class="h5">><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div>