<div dir="ltr">I think the easiest path forward is to keep getPersonalityFn returning a Constant and make this a dyn_cast. I'm halfway done with fixing it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 11:19 AM, David Blaikie via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+Majnemer, since he's been mucking about with this stuff recently</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 11:14 AM, Pete Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>(Moving to LLVM-dev). I hope thats ok to just move the conversation over from commits.</div><div><br></div><div>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><br></div><div><blockquote type="cite"><div>On Aug 31, 2015, at 11:06 AM, Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>> wrote:</div><br><div>
<div text="#000000" bgcolor="#FFFFFF">
<div>I think this question should be moved
to llvm-dev. </div></div></div></blockquote>Yep, makes sense.<br><blockquote type="cite"><div><div text="#000000" bgcolor="#FFFFFF"><div>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></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></div><div>...<br><blockquote type="cite"><div><div text="#000000" bgcolor="#FFFFFF"><div>
<br>
Philip<br>
<br>
On 08/29/2015 08:56 AM, David Blaikie wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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></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></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></div><div>Pete<br><blockquote type="cite"><div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr">
<br>
(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>
<div class="gmail_quote">On Fri, Aug 28, 2015 at 5:33 PM, Pete
Cooper via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank"></a><a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi Philip
<div><br>
</div>
<div>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><br>
</div>
<div> MF->getMMI().addPersonality(MBB, cast<Function>(LPadInst->getParent()<br>
->getParent()<br>
->getPersonalityFn()<br>
->stripPointerCasts()));</div>
<div><br>
</div>
<div>We get different behavior in this code, which is able
to handle non-function personality functions.</div>
<div><br>
</div>
<div>
<div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="color:#4f8187">EHPersonality</span> <span style="color:#703daa">llvm</span>::classifyEHPersonality(<span style="color:#bb2ca2">const</span> <span style="color:#4f8187">Value</span> *Pers) {</div>
<div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(49,89,93)"><span> </span><span style="color:#bb2ca2">const</span><span> </span><span style="color:#4f8187">Function</span><span> *F = </span>dyn_cast<span><</span><span style="color:#4f8187">Function</span><span>>(Pers-></span>stripPointerCasts<span>());</span></div>
<div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">
<span style="color:#bb2ca2">if</span> (!F)</div>
<div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(79,129,135)"><span> </span><span style="color:#bb2ca2">return</span><span> </span>EHPersonality<span>::</span><span style="color:#31595d">Unknown</span><span>;</span></div>
</div>
<div><br>
</div>
<div>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><br>
</div>
<div>So i’m not sure exactly what behavior we want.</div>
<div><br>
</div>
<div>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><br>
</div>
<div>Comments welcome, including the possibility that this
is completely wrong and that we do want to support other
values as personalities.</div>
<div><br>
</div>
<div>Cheers</div>
<span><font color="#888888">
<div>Pete</div>
<div><br>
</div>
</font></span></div>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a 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">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div></blockquote></div><br></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>