Improve maybe_hot handling in inliner heuristics

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.