[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] Clang devirtualization proposal
From: Richard Smith <richard () metafoo ! co ! uk>
Date: 2015-07-26 0:43:37
Message-ID: CAOfiQqnfEf1Z0jfMPX+CEQD0MqKV8MEdwZJyik6yb14FQhm_4Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Jul 25, 2015 at 12:39 PM, Hal Finkel <hfinkel@anl.gov> wrote:
> Hi Piotr,
>
> Thanks for posting this! First, a question. When you say, regarding i8*
> @llvm.invariant.group.barrier(i8*):
>
> "Required to handle destructors, placement new and std::launder. Call of
> this function will be put on the end of each of this functions"
>
> I completely understand placement new and std::launder. I don't understand
> destructors, could you explain?
>
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.
> 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?
>
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).
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.
struct A {
> virtual void foo() = 0;
> };
>
> struct B final : public A {
> void foo();
> };
>
> void entry(B *b) {
> // emit assumptions about vtbl of 'b' here?
>
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.
> }
>
> Thanks again,
> Hal
>
> ----- Original Message -----
> > From: "Piotr Padlewski" <prazek@google.com>
> > To: "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>,
> llvmdev@cs.uiuc.edu
> > Cc: "Richard Smith" <richard@metafoo.co.uk>
> > Sent: Wednesday, July 22, 2015 4:55:43 PM
> > Subject: [cfe-dev] Clang devirtualization proposal
> >
> >
> >
> >
> > Hi folks,
> > this summer I will work with Richard Smith on clang devirtualization.
> > Check out our proposal:
> >
> >
> https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing
> >
> >
> >
> > And modified LangRef
> > http://reviews.llvm.org/D11399
> >
> >
> >
> > You can also check out previous disscussion that was started before
> > our proposal was ready -
> > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-July/044052.html
> >
> >
> > Regards
> > Piotr Padlewski
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
[Attachment #5 (text/html)]
<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_doc \
ument_d_1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA_edit-3Fusp-3Dsharing&d=AwMFaQ&c=8 \
hUWFZcy2Z-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_D11 \
399&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>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic