https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #15 from Luke Dalessandro ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #14 from Chris Elrod ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #13 from Eric Gallager ---
(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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #12 from Jonathan Wakely ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #11 from Eric Gallager ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #10 from Jonathan Wakely ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #9 from Jonathan Wakely ---
Another solution is just to use __builtin_expect or [[likely]] or [[unlikely]]
at the call site. That wouldn't need any compiler changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #8 from Jan Hubicka ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #7 from Jonathan Wakely ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #6 from Jan Hubicka ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #5 from Jonathan Wakely ---
But it wouldn't be redundant for GCC, it would have a different, non-portable
meaning. Does it say "inline constexpr" because the code was written by someone
who likes redundancy for the sake of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #4 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Eric Gallager from comment #2)
> > I would prefer this second approach.
>
> The downside of it is that it requires adding a keyword that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #3 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #2)
> I would prefer this second approach.
The downside of it is that it requires adding a keyword that the standard says
is completely redundant, in order to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
16 matches
Mail list logo
