<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 19, 2019 at 10:36 AM Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" 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:1px solid 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:1px solid 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></div></blockquote><div><br>The discussion here seems fine - I was/am a bit confused by this involving a paper to the C++ committee.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Does P1832's approach seem like a reasonable extension <i>in the context of Clang?</i> </div></div></div></blockquote><div><br>Wording pedantry, etc - but I wouldn't describe this as an extension because it's not part of the observable behavior as far as C++ is concerned. (it doesn't make code that would be invalid (or unspecified, IB, or UB) valid with some specific semantics)<br><br>I'd probably describe it as a clang feature request - one I personally would be pretty hesitant about, but data could help motivate the decision - performance data combined with some attempt to quantify debuggability.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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:1px solid 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:1px solid 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></div></blockquote><div><br>That seems different to me - users can debug into templates and it can be useful - if they've corrupted the state of a container (yeah, other tools might be better there, like sanitizers) or the library is doing the right thing but it's surprising because the user didn't realize what they were asking for.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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></div></blockquote><div><br>Once you inline though, the code you've inlined can get jumbled up with the other code - potentially placing a container in an invalid state inside that user code - perhaps they try to print the contents of the container on a line after something was added but it doesn't show up because of instruction reordering, for instance.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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>
</blockquote></div></div>