<div dir="ltr"><div dir="ltr">On Mon, Aug 19, 2019 at 1:25 PM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Aug 19, 2019 at 8:34 AM Jon Chesterfield via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>There's a proposal in SG15 (<a href="http://wg21.link/p1832" target="_blank">http://wg21.link/p1832</a>) with a suggestion to more aggressively inline functions included via isystem when building for -Og. </div></div></blockquote><div><br>To me that sounds pretty outside the scope of the C++ standards committee, but don't know too much about how they deal with things on the fringe like this. It would seem simpler/more direct to provide patches/discuss development in existing compilers to demonstrate the value and leave it up to "market forces" to handle this sort of quality-of-implementation thing.<br></div></div></div></blockquote><div><br></div><div>I think "discuss development in existing compilers" was the purpose of Jon's opening this thread, yeah?</div><div>Does P1832's approach seem like a reasonable extension <i>in the context of Clang?</i> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The goal is to improve runtime performance for debug builds that make heavy use of the STL.</div><div><br></div><div>Does clang already set various attributes based on whether a function was found via -i or -isystem, and if not, does that seem a reasonable extension?</div></div></blockquote><div><br>Nope - pretty sure it doesn't & probably tries fairly hard not to vary code generation (or even diagnostics, except for a very big slice around system headers specifically to avoid warnings users can't fix) depending on where the code was written.<br></div></div></div></blockquote><div><br></div><div>In -Og mode, it seems that it would equally make sense to take "a very big slice around system headers specifically to avoid" debug symbols for code that users can't debug.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>There is work in Clang/LLVM to try to make -Og/-O1 (currently synonymous and hope to keep them that way as long as possible) be a good/better fast/debuggable tradeoff. But mostly that centers around avoiding destructive optimizations & keeping as much debug-ability-related state as possible.<br></div></div></div></blockquote><div><br></div><div>Are "debug symbols / lack of inlining" for any piece of code always "debuggability-related"?</div><div>P1832 takes the position that for code in system headers, performing inlining and other optimizations doesn't have much impact on "debuggability" because that system code is never going to be debugged by the user anyway.</div><div><br></div><div>Naïvely, it seems to me like a reasonable extension, in the context of Clang.</div><div><br></div><div>my $.02,</div><div>–Arthur</div></div></div>