[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I just noticed this PR and wonder if there is anything to do on inliner side. 
It uses DECL_DECLARED_INLINE that was invented to distinguish between implicit
inlines and explicit ones. So even if it would be bit misnamed it should mean
"this is an inline hint for inliner", so I guess frontend needs to distinguish
between constexpr and normal places where inline hint still means "inline
more"?

Inliner is really not on level to be able to completely ignore used inline
hints without regressing various code.

I made inline weaker for -O2 in GCC10 but for -O3 we still take it very
seriously and I do not see way out of that: in many cases it is very hard to
predict how much optimization will happen after inlining and a lot of code is
carefully crafted under assumption that some specific inline happens (and a lot
of such code is in C++)

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think we might want to add __attribute__((cold)) to std::vector functions
that are now implicitly inline due to the addition of `constexpr`. We probably
don't want to use noinline as that's too strong.

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Note that cold attribute is also quite strong since it turns optimize_size
codegen that is often a lot slower.

Reading the discussion again, I don't think we have a way to make inline
keyword ignored by inliner.  We can make not_really_inline attribute (better
name would be welcome).

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Another solution is just to use __builtin_expect or [[likely]] or [[unlikely]]
at the call site. That wouldn't need any compiler changes.

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
N.B. If you're going to do any more profiling + optimizing of std::vector,
please do it with -std=gnu++20 so that everything is constexpr. Otherwise
you're only testing C++17 which is the last version before everything in
std::vector becomes constexpr. For the later standards the optimizations will
probably behave very differently.

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #11 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #8)
> Reading the discussion again, I don't think we have a way to make inline
> keyword ignored by inliner.  We can make not_really_inline attribute (better
> name would be welcome).

"fake_inline"?

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
There's nothing fake about them, they are definitely inline functions as far as
the language rules. But in some cases we don't want the compiler to use that
fact as an optimisation hint.

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #13 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #12)
> There's nothing fake about them, they are definitely inline functions as far
> as the language rules. But in some cases we don't want the compiler to use
> that fact as an optimisation hint.

"quasi_inline"? "pseudo_inline"? "unoptimizable_inline"? "strictly_inline"?
"honorary_inline"? "inline_in_name_only"? "ceremonially_inline"?

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[elrodc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #14 from Chris Elrod <elrodc at gmail dot com> ---
To me, an "inline" function is one that the compiler inlines.
It just happens that the `inline` keyword also means both comdat semantics, and
possibly hiding the symbol to make it internal (-fvisibility-inlines-hidden).
It also just happens to be the case that the vast majority of the time I mark a
function `inline`, it is because of this, not because of the compiler hint.
`static` of course also specifies internal linkage, but I generally prefer the
comdat semantics: I'd rather merge than duplicate the definitions.

If there is a new keyword or pragma meaning comdat semantics (and preferably
also specifying internal linkage), I would rather have the name reference that.

I'd rather have a positive name about what it does, than negative:
"quasi_inline: like inline, except it does everything inline does except the
inline part".
Why define as a set diff -- naming it after the thing it does not do! -- if you
could define it in the affirmative, based on what it does in the first place?

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

[ldalessandro at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008

--- Comment #15 from Luke Dalessandro <ldalessandro at gmail dot com> ---
(In reply to Jonathan Wakely from comment #5)

> 
> IMO the ideal solution is for GCC to stop using whether a function is inline
> as an optimisation hint. Then we wouldn't need some extra GCC-specific way
> to override that.

I'd vote to just do this and provide an attribute that's weaker than
[[gnu::always_inline]] for those that need it. No need to change any underlying
language stuff.