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

[Lubos Lunak via cfe-dev]

On Tuesday 20 of August 2019, via cfe-dev wrote:
> Ah, I'd forgotten that Og prefers not to inline.
> Distinguishing optimization levels within one translation unit is tricky
> given the current way we build optimization pipelines. They are *not*
> designed to handle function-level differences in optimization levels. 
> Trying to (essentially) mix O1 and O2 in the same translation unit is a
> radical departure from how LLVM thinks about optimization.  ('optnone' is a
> special case where passes effectively disable themselves when presented
> with an 'optnone' function. Generalizing that to more optimization levels
> is a seriously invasive proposition.)


 It seems to me you see in this more than there is. Read the original mail 
again: "a suggestion to more aggressively inline functions included via 
isystem when building for -Og." That, in other words, can be also said 
as "treat all functions from -isystem as if they have 
__attribute__((always_inline)) by default". Or just read the green section in 
http://wg21.link/p1832 , that's yet another way of putting it.

 And that's it. And it's not a radical departure from anything LLVM does, 
because __attribute__((always_inline)) already works. And defaulting -isystem 
functions to having the attribute is probably a few lines of code. Another 
few lines of code if this would be controlled by a command line option.

-- 
 Lubos Lunak