<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 25, 2015 at 12:39 PM, 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">Hi Piotr,<br>
<br>
Thanks for posting this! First, a question. When you say, regarding i8* @llvm.invariant.group.barrier(i8*):<br>
<br>
"Required to handle destructors, placement new and std::launder. Call of this function will be put on the end of each of this functions"<br>
<br>
I completely understand placement new and std::launder. I don't understand destructors, could you explain?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
struct A {<br>
  virtual void foo() = 0;<br>
};<br>
<br>
struct B final : public A {<br>
  void foo();<br>
};<br>
<br>
void entry(B *b) {<br>
 // emit assumptions about vtbl of 'b' here?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
}<br>
<br>
Thanks again,<br>
Hal<br>
<span class="im HOEnZb"><br>
----- Original Message -----<br>
> From: "Piotr Padlewski" <<a href="mailto:prazek@google.com">prazek@google.com</a>><br>
> To: "<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>>, <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
> Cc: "Richard Smith" <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
> Sent: Wednesday, July 22, 2015 4:55:43 PM<br>
> Subject: [cfe-dev] Clang devirtualization proposal<br>
><br>
><br>
><br>
><br>
> Hi folks,<br>
> this summer I will work with Richard Smith on clang devirtualization.<br>
> Check out our proposal:<br>
><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA_edit-3Fusp-3Dsharing&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=a-zDi7sVLAxtqqkNaK_FrhnctPqM_zCuB2JXhyOxwXQ&s=E1mu4U3B2Hcdv28SfDoWqgTWIyiEE2LigER8m4-DdqM&e=" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing</a><br>
><br>
><br>
><br>
</span><span class="im HOEnZb">> And modified LangRef<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11399&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=a-zDi7sVLAxtqqkNaK_FrhnctPqM_zCuB2JXhyOxwXQ&s=UyZf6QNX_ZxlIzmhEg6v7aUiT7LkjMDZLBHPn8VMHSA&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11399</a><br>
><br>
><br>
><br>
</span><span class="im HOEnZb">> You can also check out previous disscussion that was started before<br>
> our proposal was ready -<br>
> <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-July/044052.html" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-July/044052.html</a><br>
><br>
><br>
</span><span class="im HOEnZb">> Regards<br>
> Piotr Padlewski<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
<br>
</span><div class="HOEnZb"><div class="h5">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>