<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Menlo;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:1376277128;
mso-list-type:hybrid;
mso-list-template-ids:-887168508 1504336678 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
mso-ascii-font-family:Calibri;
mso-fareast-font-family:Calibri;
mso-hansi-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I think a question was glossed over. Exactly which directions should be inlined…<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">User callee into user caller (definitely not)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">System callee into system caller (yes)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">User callee into system caller (maybe?)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">System callee into user caller (maybe?)<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Perhaps number 3 should be prohibited because then a breakpoint on “my” function would either not get hit, or turn into multiple breakpoints.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Perhaps number 4 should be prohibited because it makes stepping across loop iterations in things like std::transform more difficult.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> cfe-dev <cfe-dev-bounces@lists.llvm.org>
<b>On Behalf Of </b>via cfe-dev<br>
<b>Sent:</b> Tuesday, August 20, 2019 12:59 PM<br>
<b>To:</b> arthur.j.odwyer@gmail.com<br>
<b>Cc:</b> jonathanchesterfield@gmail.com; john@mcfarlane.name; cfe-dev@lists.llvm.org<br>
<b>Subject:</b> [EXTERNAL] Re: [cfe-dev] Varying per function optimisation based on include path?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Ah, I'd forgotten that Og prefers not to inline.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Distinguishing optimization levels within one translation unit is tricky given the current way we build optimization pipelines. They are *not* designed to handle
function-level differences in optimization levels. Trying to (essentially) mix O1 and O2 in the same translation unit is a radical departure from how LLVM thinks about optimization. ('optnone' is a special case where passes effectively disable themselves
when presented with an 'optnone' function. Generalizing that to more optimization levels is a seriously invasive proposition.)<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">Re the "symbols" confusion, broadly speaking you can separate debug info into that which describes the source (types, variables, etc), and that which describes
the generated code (to a first approximation, the instruction<->source mapping). So the suggestion in this thread is to retain the former but not the latter.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">In this exercise, if we genuinely want to *prevent* debugging of defined-in-system-header functions (which seems like a highly questionable feature) it could
be done with judicious application of the 'nodebug' attribute. Not hard, really.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">--paulr<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 style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> Arthur O'Dwyer [<a href="mailto:arthur.j.odwyer@gmail.com">mailto:arthur.j.odwyer@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, August 20, 2019 12:20 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> Jon Chesterfield; Clang Dev; John McFarlane<br>
<b>Subject:</b> Re: [cfe-dev] Varying per function optimisation based on include path?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Aug 20, 2019 at 9:42 AM via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">> In -Og mode, it seems that it would equally make sense to take "a very big<br>
> slice around system headers specifically to avoid" debug symbols for code<br>
> that users can't debug.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_3359278419428531052__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></a><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Our users seem to like to be able to dump their STL containers, which definitely requires debug symbols
for "code they can't debug."</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Hmm, I may have muddled things up by mentioning "debug symbols" without fully understanding what people mean by that phrase precisely. I meant "line-by-line debugging information enabling single-step through a bunch of templates that the
user doesn't care about and would prefer to see inlined away." Forget debug symbols and focus on inlining, if that'll help avoid my confusion. :)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">OTOH being able to more aggressively optimize system-header code even in –Og mode seems reasonable.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">OTOOH most of the system-header code is templates or otherwise inlineable early, and after inlining
the distinction between app and sys code really goes away.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I believe we'd like to get "inlining early," but the problem is that `-Og` disables inlining. So there is no "after inlining" at the moment.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Here's a very concrete example: <a href="https://urldefense.com/v3/__https:/godbolt.org/z/5tTgO4__;!fqWJcnlTkjM!7ZGRlXoS3ERcBoHUI0twkSwgjy1q68aYJaN5WYHvdmN5-ryxMXzEwmUQRCfC$">https://godbolt.org/z/5tTgO4</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">int foo(std::tuple<int, int> t) {<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> return std::get<0>(t);<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">}<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">At `-Og` this produces the assembly code<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">_Z3fooSt5tupleIJiiEE:<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> pushq %rax<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> callq _ZSt3getILm0EJiiEERNSt13tuple_elementIXT_ESt5tupleIJDpT0_EEE4typeERS4_<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> movl (%rax), %eax<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> popq %rcx<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> retq<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">_ZSt3getILm0EJiiEERNSt13tuple_elementIXT_ESt5tupleIJDpT0_EEE4typeERS4_:<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> jmp _ZSt12__get_helperILm0EiJiEERT0_RSt11_Tuple_implIXT_EJS0_DpT1_EE<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">_ZSt12__get_helperILm0EiJiEERT0_RSt11_Tuple_implIXT_EJS0_DpT1_EE:<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> jmp _ZNSt11_Tuple_implILm0EJiiEE7_M_headERS0_<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">_ZNSt11_Tuple_implILm0EJiiEE7_M_headERS0_:<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> addq $4, %rdi<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> jmp _ZNSt10_Head_baseILm0EiLb0EE7_M_headERS0_<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">_ZNSt10_Head_baseILm0EiLb0EE7_M_headERS0_:<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> movq %rdi, %rax<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> retq<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I believe that if John McFarlane's proposal were adopted by Clang, so that inlining-into-system-functions were allowed at `-Og`, then the resulting assembly code would look like this instead, for a much better experience in both debugging
and runtime performance:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">_Z3fooSt5tupleIJiiEE:<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> pushq %rax<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> callq _ZSt3getILm0EJiiEERNSt13tuple_elementIXT_ESt5tupleIJDpT0_EEE4typeERS4_<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> movl (%rax), %eax<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> popq %rcx<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> retq<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black">_ZSt3getILm0EJiiEERNSt13tuple_elementIXT_ESt5tupleIJDpT0_EEE4typeERS4_:<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> leaq 4(%rdi), %rax<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;font-stretch:normal"><span style="font-size:10.0pt;font-family:"Menlo",serif;color:black"> retq<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Notice that we still aren't inlining `std::get` into `foo`, because `foo` (as a user function) gets no inlining optimizations at `-Og`. But we do inline and collapse the whole chain of function-template helpers into `std::get` (because
`std::get` is a function <b><i>defined</i></b> in a system header). This inlining creates new optimization opportunities, such as combining the `add` and `mov` into a single `lea`.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">HTH,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">–Arthur<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>