<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">(Moving to LLVM-dev). I hope thats ok to just move the conversation over from commits.</div><div class=""><br class=""></div><div class="">To summarise, selection DAG crashes if personality functions are not actually functions. This conversation is to try work out if that is a restriction we want to document in LangRef, or (as David B suggests), we should allow opaque values to be personality functions. I don’t actually know EH code at all, so I don’t know what the right answer is.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Aug 31, 2015, at 11:06 AM, Philip Reames <<a href="mailto:listmail@philipreames.com" class="">listmail@philipreames.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">I think this question should be moved
to llvm-dev. </div></div></div></blockquote>Yep, makes sense.<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix">David's point is completely reasonable, but I think
we generally assume personality functions are functions today.
I'd be tempted to modify the verifier as Pete suggests, but we
should get broader input before actually doing so. Given how
vague the LangRef is today, restricting personality functions to
be direct calls could be construed as a LangRef change.<br class=""></div></div></div></blockquote>Yeah, this is a little vague. Considering the code in SelectionDAGBuilder will always crash if we have a non-Function*, I believe that means we could never have actually codegen-ed any of the code I had to fix in test cases.</div><div><br class=""></div><div>...<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix">
<br class="">
Philip<br class="">
<br class="">
On 08/29/2015 08:56 AM, David Blaikie wrote:<br class="">
</div>
<blockquote cite="mid:CAENS6EuLprP_eFQ9tisNAQ+b3Pag+_CUhZ-DMky5KKQ6n-LcpA@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">Knowing nothing about any of this stuff, I do find
this a bit surprising - usually values are opaque to their
consumers: they're just a value.<br class=""></div></blockquote></div></div></blockquote>So i actually know nothing about this either. When i originally found the crash, personality functions were still on the LandingPadInst itself.</div><div><br class=""></div><div>I agree that typically its fine to be able to use opaque values. Unless we actually have to introspect the personality Function*, eg, for calling conventions, then I think its fine to allow any value. In fact, it looks like classifyEHPersonality was written to support this.</div><div><br class=""></div><div>Pete<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote cite="mid:CAENS6EuLprP_eFQ9tisNAQ+b3Pag+_CUhZ-DMky5KKQ6n-LcpA@mail.gmail.com" type="cite" class=""><div dir="ltr" class="">
<br class="">
(especially with pointer bitcasts (which will go away,
eventually) - if I have a global variable I've put some
executable bytes in and I cast a pointer to that global variable
to a pointer to a function, I would expect that should be
interchangeable...)</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Fri, Aug 28, 2015 at 5:33 PM, Pete
Cooper via llvm-commits <span dir="ltr" class=""><<a moz-do-not-send="true" href="mailto:llvm-commits@lists.llvm.org" target="_blank" class=""></a><a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">Hi Philip
<div class=""><br class="">
</div>
<div class="">While reducing a test case with personality
functions, I crashed selection DAG. The reason being
that my personality function was no longer a function.
The relevant code is</div>
<div class=""><br class="">
</div>
<div class=""> MF->getMMI().addPersonality(MBB, cast<Function>(LPadInst->getParent()<br class="">
->getParent()<br class="">
->getPersonalityFn()<br class="">
->stripPointerCasts()));</div>
<div class=""><br class="">
</div>
<div class="">We get different behavior in this code, which is able
to handle non-function personality functions.</div>
<div class=""><br class="">
</div>
<div class="">
<div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo" class=""><span style="color:#4f8187" class="">EHPersonality</span> <span style="color:#703daa" class="">llvm</span>::classifyEHPersonality(<span style="color:#bb2ca2" class="">const</span> <span style="color:#4f8187" class="">Value</span> *Pers) {</div>
<div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(49,89,93)" class=""><span style="" class=""> </span><span style="color:#bb2ca2" class="">const</span><span style="" class=""> </span><span style="color:#4f8187" class="">Function</span><span style="" class=""> *F = </span>dyn_cast<span style="" class=""><</span><span style="color:#4f8187" class="">Function</span><span style="" class="">>(Pers-></span>stripPointerCasts<span style="" class="">());</span></div>
<div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo" class="">
<span style="color:#bb2ca2" class="">if</span> (!F)</div>
<div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(79,129,135)" class=""><span style="" class=""> </span><span style="color:#bb2ca2" class="">return</span><span style="" class=""> </span>EHPersonality<span style="" class="">::</span><span style="color:#31595d" class="">Unknown</span><span style="" class="">;</span></div>
</div>
<div class=""><br class="">
</div>
<div class="">And finally, LangRef itself implies that its a
function as it says that we should 'specify what
function to use for exception handling’.</div>
<div class=""><br class="">
</div>
<div class="">So i’m not sure exactly what behavior we want.</div>
<div class=""><br class="">
</div>
<div class="">However, assuming we do want personality functions to
always actually be functions (which was what i
originally thought we wanted), here’s a patch which
teaches the verifier this.</div>
<div class=""><br class="">
</div>
<div class="">Comments welcome, including the possibility that this
is completely wrong and that we do want to support other
values as personalities.</div>
<div class=""><br class="">
</div>
<div class="">Cheers</div>
<span class="HOEnZb"><font color="#888888" class="">
<div class="">Pete</div>
<div class=""><br class="">
</div>
</font></span></div>
<br class="">
<br class="">
_______________________________________________<br class="">
llvm-commits mailing list<br class="">
<a moz-do-not-send="true" href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a><br class="">
<a moz-do-not-send="true" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Dcommits&d=BQMDaQ&c=eEvniauFctOgLOKGJOplqw&r=03tkj3107244TlY4t3_hEgkDY-UG6gKwwK0wOUS3qjM&m=osq1cWQ7EmXsSMMetgDarRODQ97erXe70D8IoZAGoTM&s=eMTJOIwzYQF_n2Vl-3YdQp5usXIGF5Xfo1FT82cuyt0&e=" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></body></html>