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

[Arthur O'Dwyer via cfe-dev]

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?
Does P1832's approach seem like a reasonable extension *in the context of
Clang?*

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.

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.

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/4c65f328/attachment.html>