<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;}
@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
{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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@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"><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"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></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 [mailto:arthur.j.odwyer@gmail.com]
<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-right:0in">
<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-right:0in">
<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://godbolt.org/z/5tTgO4">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>
</body>
</html>