https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119978
Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |siddhesh at gcc dot gnu.org
--- Comment #2 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> ---
This appears to have been fixed with r16-372:
commit 064cac730f88dc71c6da578f9ae5b8e092ab6cd4
Author: Jan Hubicka <[email protected]>
Date: Sun May 4 10:52:35 2025 +0200
Improve maybe_hot handling in inliner heuristics
Inliner currently applies different heuristics to hot and cold calls (the
second are inlined only if the code size will shrink). It may happen that
the
call itself is hot, but the significant time is spent in callee and
inlining
makes it faster. For this reason we want to check if the anticipated
speedup
is considered hot which is done by this patch (that is similar ot my
earlier
ipa-cp change).
In general I think this is less important compared to ipa-cp change, since
large
benefit from inlining happens only when something useful is propagated into
the
callee and should be handled earlier by ipa-cp. However the patch improves
SPEC2k17 imagick runtime by about 9% as discussed in PR 11900 though it is
mostly problem of bad train data set which does not train well parts of
program
that are hot for ref data set. As discussed in the PR log, the particular
call
that needs to be inlined has count that falls very slightly bellow the
cutoff
and scaling it up by expected savings enables inlining.
gcc/ChangeLog:
PR target/119900
* cgraph.cc (cgraph_edge::maybe_hot_p): Add
a variant accepting a sreal scale; use reliability of
profile.
* cgraph.h (cgraph_edge::maybe_hot_p): Declare
a varaint accepting a sreal scale.
* ipa-inline.cc (callee_speedup): New function.
(want_inline_small_function_p): add early return
and avoid duplicated lookup of summaries; use scaled
maybe_hot predicate.
