<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 18, 2015 at 4:36 PM, Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div><span class="">
<p class="MsoNormal"><span style="color:#1f497d">> </span>optimizing EH codepaths is not usually performance critical.<u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">>> </span>Leaving aside the rest of the thread, I feel the need to refute this point in isolation.  I've found that optimizing (usually simplifying and eliminating) exception paths ends up being *extremely* important
 for my workloads.  Failing to optimize exception paths sufficiently tends to indirectly hurt things like inlining for example.  Any design which starts with the assumption that optimizing exception paths isn't important is going to be extremely problematic
 for me.  <br></p></span></div></div></blockquote><div><br></div><div>On the whole, the whole reason we've gone down this path is to support stronger analysis of EH paths, but I always think about it in terms of supporting simplification of the normal control flow path. Consider unique_ptr:</div><div><br></div><div>void f() {</div><div>  std::unique_ptr<int> p(new int(42));</div><div>  g(p.get());<br>}</div><div><br></div><div>This representation should support removing the heap allocation here by inlining the destructor on the normal path and EH path and promoting the heap allocation to a stack allocation. If our representation required early outlining, this would not be possible, or at least it would require inter-procedural analysis.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div><span class=""><p class="MsoNormal">
<u></u><u></u></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That’s interesting. 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I wasn’t thinking about performance so much as code size in my original comment.  I’ve been looking at IR recently where code from multiple exception handlers
 was combined while still maintaining the basic control flow of the EH code.  This kind of optimization is wreaking havoc for our current MSVC compatible EH implementation (hence the redesign), but I guess the Itanium ABI scheme doesn’t have a problem with
 it.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I suppose that is closely related to your concerns about inlining, I just hadn’t made the connection.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In theory the funclets should be able to share code blocks without any problem.  The entry and exit points are the critical parts that make them funclets. 
 I’m just not sure how we can get the optimization passes to recognize this fact while still meeting the MSVC runtime constraints.  Reid’s proposal of separate catch blocks should help with that, but I’m still not sure we’ll want to use this representation
 for targets that don’t need it.</span></p></div></div></blockquote><div><br></div>I think sharing code between funclets would require some extreme gymnastics to generate the right pdata and xdata, but I suppose it's not too different from what MSVC 2015 requires for coroutines.</div></div></div>