<div dir="auto"><div><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" rel="noreferrer noreferrer" target="_blank">arthur.j.odwyer@gmail.com</a>></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
wrote:<br>
<br>
> On Mon, Aug 19, 2019 at 1:25 PM David Blaikie via cfe-dev <<br>
> <a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
>> On Mon, Aug 19, 2019 at 8:34 AM Jon Chesterfield via cfe-dev <<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>>><br>
>>> There's a proposal in SG15 (<a href="http://wg21.link/p1832" rel="noreferrer noreferrer noreferrer" target="_blank">http://wg21.link/p1832</a>) with a suggestion<br>
>>> to more aggressively inline functions included via isystem when building<br>
>>> for -Og.<br>
>>><br>
>><br>
>> To me that sounds pretty outside the scope of the C++ standards<br>
>> committee, but don't know too much about how they deal with things on the<br>
>> fringe like this. It would seem simpler/more direct to provide<br>
>> patches/discuss development in existing compilers to demonstrate the value<br>
>> and leave it up to "market forces" to handle this sort of<br>
>> quality-of-implementation thing.<br>
>><br>
><br>
> I think "discuss development in existing compilers" was the purpose of<br>
> Jon's opening this thread, yeah?<br>
><br>
<br>
The discussion here seems fine - I was/am a bit confused by this involving<br>
a paper to the C++ committee.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It's context. Most of the time I'm compiler back end, but periodically I play with C++. John's paper looked enough like a compiler bug report that I thought I'd raise it here. The paper references GCC but LLVM is more familiar to me.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Does P1832's approach seem like a reasonable extension *in the context of<br>
> Clang?*<br>
><br>
<br>
Wording pedantry, etc - but I wouldn't describe this as an extension<br>
because it's not part of the observable behavior as far as C++ is<br>
concerned. (it doesn't make code that would be invalid (or unspecified, IB,<br>
or UB) valid with some specific semantics)<br>
<br>
I'd probably describe it as a clang feature request - one I personally<br>
would be pretty hesitant about, but data could help motivate the decision -<br>
performance data combined with some attempt to quantify debuggability.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Feature request is fair. I was imagining marking "application" functions as optnone and STL/SDK functions as normal, but don't have a good handle on how clang distinguishes functions from different origins.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The goal is to improve runtime performance for debug builds that make<br>
>>> heavy use of the STL.<br>
>>><br>
>>> Does clang already set various attributes based on whether a function<br>
>>> was found via -i or -isystem, and if not, does that seem a reasonable<br>
>>> extension?<br>
>>><br>
>><br>
>> Nope - pretty sure it doesn't & probably tries fairly hard not to vary<br>
>> code generation (or even diagnostics, except for a very big slice around<br>
>> system headers specifically to avoid warnings users can't fix) depending on<br>
>> where the code was written.<br>
>><br>
><br>
> 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.<br>
><br>
<br>
That seems different to me - users can debug into templates and it can be<br>
useful - if they've corrupted the state of a container (yeah, other tools<br>
might be better there, like sanitizers) or the library is doing the right<br>
thing but it's surprising because the user didn't realize what they were<br>
asking for.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Mixed. The attitude of "the bug is in my code, not the standard library" is usually worth encouraging. So I sort of like the idea of optimising library code while keeping application code simpler. Splitting the two by include paths was a new idea for me.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> There is work in Clang/LLVM to try to make -Og/-O1 (currently synonymous<br>
>> and hope to keep them that way as long as possible) be a good/better<br>
>> fast/debuggable tradeoff. But mostly that centers around avoiding<br>
>> destructive optimizations & keeping as much debug-ability-related state as<br>
>> possible.<br>
>><br>
><br>
> Are "debug symbols / lack of inlining" for any piece of code always<br>
> "debuggability-related"?<br>
> P1832 takes the position that for code in system headers, performing<br>
> inlining and other optimizations doesn't have much impact on<br>
> "debuggability" because that system code is never going to be debugged by<br>
> the user anyway.<br>
><br>
<br>
Once you inline though, the code you've inlined can get jumbled up with the<br>
other code - potentially placing a container in an invalid state inside<br>
that user code - perhaps they try to print the contents of the container on<br>
a line after something was added but it doesn't show up because of<br>
instruction reordering, for instance.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Sure. This suggestion is a rough line between code that is "trusted" and "suspect", at slightly different granularity to compiling different translation units with different optimisation levels.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> Naïvely, it seems to me like a reasonable extension, in the context of<br>
> Clang.<br>
><br>
> my $.02,<br>
> –Arthur<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Cheers. Naively seems reasonable is where I am on this. It feels like something games dev people would like. And it feels more QoI than ISO. Good debugging experience of optimised code is, uh, difficult.</div><div dir="auto"><br></div><div dir="auto">Jon</div></div>