<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Yes and more. I'm pretty sure you can use the variables in the handler, and maybe change them.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">I *think*:</p>
<p style="margin-top:0;margin-bottom:0">You can read them either from Context or more likely DispatcherContext->Context.</p>
<p style="margin-top:0;margin-bottom:0"> I think the first is at the point of the exception and the second is having unwound to this handler, so the second.</p>
<p style="margin-top:0;margin-bottom:0">You can write them by calling RtlVirtualUnwind until EstablisherFrame matches where you want to unwind to, and using the ContextPointers is offers.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">i.e. instead of only using the EstablisherFrame.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">i.e. I believe the intent of the design is that exception handling still allows pretty much all optimization you would have done w/o EH (at the cost of having to generate data, for example chained unwind for shrink wrapping,
and possibly cumbersome access in the handler, etc.).<span style="font-size: 12pt;">.</span></p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size: 12pt;">I wish the documentation was clearer here.</span><br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size: 12pt;">I can't argue if it fits into the larger framework.</span><br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"> - Jay</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Reid Kleckner <rnk@google.com><br>
<b>Sent:</b> Thursday, May 24, 2018 8:00 PM<br>
<b>To:</b> jayk123@hotmail.com<br>
<b>Cc:</b> llvm-dev<br>
<b>Subject:</b> Re: [llvm-dev] LLVM SEH docs -- enregistration of locals in nonvolatile registers?</font>
<div> </div>
</div>
<meta content="text/html; charset=utf-8">
<div>
<div dir="ltr">Is this example what you had in mind?
<div><br>
</div>
<div>void f() {</div>
<div> int *p = get_p();</div>
<div> use_p(p);</div>
<div> try {</div>
<div> may_throw(p);<br>
} catch (int) {</div>
<div> // don't need p</div>
<div> }</div>
<div> use_p(p);<br>
}</div>
<div><br>
</div>
<div>The idea is that because p is not modified or used within the catch region (the funclet), it can live in a callee-saved register across the whole function.</div>
<div><br>
</div>
<div>That is true, it is possible, but I don't think it fits very well in our current model and CFG. Given that it doesn't fit the model, I don't think it's helpful to try to explain this in the documentation. The document is intended to aid LLVM developers
who don't particularly care about WinEH but want to understand it enough to avoid breaking it.</div>
<div><br>
</div>
<div>If we wanted to exploit this optimization opportunity, we would clip funclets out of the CFG and add edges from invokes to all possible catchret destinations. Then the CSR mask of the call would naturally provide the right register allocation barrier.</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr">On Thu, May 24, 2018 at 8:13 AM Jay K via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" id="LPlnk60408" class="OWAAutoLink" previewremoved="true">llvm-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<a href="https://llvm.org/docs/ExceptionHandling.html#wineh" rel="noreferrer" target="_blank" id="LPlnk37143" class="OWAAutoLink" previewremoved="true">https://llvm.org/docs/ExceptionHandling.html#wineh</a><br>
<br>
> No variables live in to or out of the funclet can be allocated in registers.<br>
<br>
I don't think this is quite true. though it might be a useful simplification.<br>
Obviously it is true for volatile registers, but I believe the funclet receives a CONTEXT<br>
with the nonvolatiles restored. Obviously cumbersome to access, but it lets you enregister them across calls like normal in the "original" function.<br>
<br>
I haven't seen Visual C++ to such enregistration (nonvolatiles across calls in functions with EH), but you can do it in assembly.<br>
<br>
nvlocala.asm here <a href="http://jaykrell2.blogspot.com/2017/10/windows-amd64-abi-nuances-part-1.html" rel="noreferrer" target="_blank" id="LPlnk614042" class="OWAAutoLink" previewremoved="true">
http://jaykrell2.blogspot.com/2017/10/windows-amd64-abi-nuances-part-1.html</a><br>
<br>
I should change it to print the nonvolatiles from context to demonstrate the point.<br>
<br>
- Jay<br>
<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" id="LPlnk41651" class="OWAAutoLink" previewremoved="true">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" id="LPlnk482636" class="OWAAutoLink" previewremoved="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>