<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 05/18/2015 04:36 PM, Kaylor, Andrew
wrote:<br>
</div>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE570FA8F0@ORSMSX115.amr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">> </span>optimizing
EH codepaths is not usually performance critical.<o:p></o:p></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>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">That’s
interesting.
</span></p>
</div>
</blockquote>
Sorry for not responding here for so long.
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE570FA8F0@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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.</span></p>
</div>
</blockquote>
Since I'm pretty sure I added at least one optimization to simplify
cfg which sounds problematic for you, sorry! :)<br>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE570FA8F0@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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.</span></p>
</div>
</blockquote>
The effect on inlining is that combining the exception handler
blocks reduces the perceived cost to inline a function with lots of
exceptional control flow. When you're coming from a language where
*every* call is an invoke and you need some per function/frame code
to recover/rethrow just about any exception (that's just an
implementation detail), commoning exceptional control flow turns out
to be rather important. <br>
<br>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE570FA8F0@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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>
</blockquote>
If you fundamentally need the funclets, I think that makes you
incompatible with the optimizations we want to support for itanium
and related ABIs. I have no problem with supporting both
separately, though I am worried about how much maintenance burden
that will create going forward. <br>
<br>
<br>
<br>
Since I haven't been following the thread closely, is there an
updated summary of the original proposal available? I know that
various parts I had concerns with (the unsplitable blocks for
instance) got addressed, but I'm having trouble tracking all the
changes in discussion. Even just a quick list of "and we changed X"
would be helpful. <br>
<br>
Philip<br>
<br>
</body>
</html>