[cfe-dev] Varying per function optimisation based on include path?

[David Blaikie via cfe-dev]

On Mon, Aug 19, 2019 at 10:36 AM Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
wrote:

> On Mon, Aug 19, 2019 at 1:25 PM David Blaikie via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Mon, Aug 19, 2019 at 8:34 AM Jon Chesterfield via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>>
>>> There's a proposal in SG15 (http://wg21.link/p1832) with a suggestion
>>> to more aggressively inline functions included via isystem when building
>>> for -Og.
>>>
>>
>> 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.
>>
>
> I think "discuss development in existing compilers" was the purpose of
> Jon's opening this thread, yeah?
>

The discussion here seems fine - I was/am a bit confused by this involving
a paper to the C++ committee.


> Does P1832's approach seem like a reasonable extension *in the context of
> Clang?*
>

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)

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.


> The goal is to improve runtime performance for debug builds that make
>>> heavy use of the STL.
>>>
>>> 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?
>>>
>>
>> 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.
>>
>
> 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.
>

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.


>
> 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.
>>
>
> Are "debug symbols / lack of inlining" for any piece of code always
> "debuggability-related"?
> 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.
>

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.


>
> Naïvely, it seems to me like a reasonable extension, in the context of
> Clang.
>
> my $.02,
> –Arthur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190819/c23fa240/attachment.html>