<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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;}
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";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">> Mixing OptNone and bisect is a software engineering bug: it's mixing different layers of abstraction. Bisect is something that's<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">> at pass manager scope: run passes until whatever. OptNone in turn doesn't belong in the pass manager layer. It only concerns<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">> function passes, and crumbles quickly considering other IRUnits or even codegen. I don't have a clear vision what OptNone<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">> handling should look like, but at this point I consider it entirely orthogonal to bisect handling.<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" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In one sense you are absolutely right, OptNone and opt-bisect are completely different things, but from the perspective of the pass
they mean exactly the same thing: should I optimize this IR unit. It’s also true that the pass shouldn’t be making that decision, and it really isn’t in the legacy implementation. It’s calling a function to ask whether or not it should perform the optimization.
That’s also less than ideal. In a perfect world, the pass wouldn’t be called at all if it should be run. I think we’re actually in agreement here with regard to OptBisect.<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" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">OptNone is out of the scope of the current proposal, but I agree that in principle the pass manager shouldn’t be handling it. On the
other hand, it’s not entirely clear to me that the pass itself should be handling it. There is nothing pass-specific in the interpretation of the OptNone attribute. The OptNone attribute says “don’t optimize this function.” So should we really be calling the
run() method of an optimization pass on a function that we aren’t supposed to be optimizing. It feels to me like there’s a missing player here. As I said, that’s really outside the scope of the current discussion except to say that the relevant question is
what component should make the decision about whether or not a pass should be run.<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"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Some historical perspective and clarification:<o:p></o:p></span></a></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">OptNone does not mean "don't optimize this function." It means "treat this function as much like –O0 would as you can." (We thrashed that one out when LTO
started tagging functions with the optnone attribute.) Those are not completely identical statements; -O0 does run some passes. Complications arise because there's only one pass pipeline in any given compilation, and the pass manager doesn't know what the
–O0 pipeline looks like, but the –O0 pipeline is not empty.<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">Passes that don't normally run at –O0 were taught to query the helper. This was not the originally proposed design, but at the time we introduced OptNone there
was serious push-back about adding a new feature to the old (at that time, only) pass manager because the new pass manager was just over the horizon. Five years later it might be time to rethink that.<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">OptBisect built on OptNone because it was there. Again there are passes that have to run to produce usable output, even if you might think of them as "optimization"
passes, they would be part of the –O0 pipeline anyway and they pretty much have to run no matter what. I'm not close enough to the problem to have a strong opinion whether OptBisect and OptNone should share an underlying mechanism, but from the sidelines
it seems like one readily understandable model for OptBisect is "go this far down the regular pipeline then turn on OptNone." Maybe a different model would work better; I'm not sure.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr</span><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>
</div>
</body>
</html>