https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119900
--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jan Hubicka <hubi...@gcc.gnu.org>: https://gcc.gnu.org/g:064cac730f88dc71c6da578f9ae5b8e092ab6cd4 commit r16-372-g064cac730f88dc71c6da578f9ae5b8e092ab6cd4 Author: Jan Hubicka <hubi...@ucw.cz> 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.
