- Generated by
1.8.1.1
|
GCC Middle and Back End API Reference
|
Variables | |
| static int | overall_size |
| static gcov_type | max_count |
| static sreal | max_count_real |
| static sreal | max_relbenefit_real |
| static sreal | half_int_min_real |
|
static |
Compute badness of all edges in NEW_EDGES and add them to the HEAP.
References cgraph_edge::caller, cgraph_resolve_speculation(), cgraph_node::global, inline_update_overall_summary(), cgraph_global_info::inlined_to, reset_edge_caches(), speculation_useful_p(), cgraph_edge::speculative, and update_caller_keys().
|
static |
Return true if the speedup for inlining E is bigger than PARAM_MAX_INLINE_MIN_SPEEDUP.
|
static |
Return false when inlining edge E would lead to violating limits on function unit growth or stack usage growth. The relative function body growth limit is present generally to avoid problems with non-linear behavior of the compiler. To allow inlining huge functions into tiny wrapper, the limit is always based on the bigger of the two functions considered. For stack growth limits we always base the growth in stack usage of the callers. We want to prevent applications from segfaulting on stack overflow when functions with huge stack frames gets inlined.
Look for function e->caller is inlined to. While doing
so work out the largest function body on the way. As
described above, we want to base our function growth
limits based on that. Not on the self size of the
outer function, not on the self size of inline code
we immediately inline to. This is the most relaxed
interpretation of the rule "do not grow large functions
too much in order to prevent compiler from exploding". Check the size after inlining against the function limits. But allow
the function to shrink if it went over the limits by forced inlining. FIXME: Stack size limit often prevents inlining in Fortran programs
due to large i/o datastructures used by the Fortran front-end.
We ought to ignore this limit when we know that the edge is executed
on every invocation of the caller (i.e. its call statement dominates
exit block). We do not track this information, yet. Check new stack consumption with stack consumption at the place
stack is used. If function already has large stack usage from sibling
inline call, we can inline, too.
This bit overoptimistically assume that we are good at stack
packing.
|
static |
Return true if the edge E is inlinable during early inlining.
Early inliner might get called at WPA stage when IPA pass adds new
function. In this case we can not really do any of early inlining
because function bodies are missing. In early inliner some of callees may not be in SSA form yet
(i.e. the callgraph is cyclic and we did not process
the callee by early inliner, yet). We don't have CIF code for this
case; later we will re-do the decision in the real inliner.
|
static |
Decide if we can inline the edge and possibly update inline_failed reason. We check whether inlining is possible at all and whether caller growth limits allow doing so. if REPORT is true, output reason to the dump file. if DISREGARD_LIMITES is true, ignore size limits.
Don't inline if the functions have different EH personalities.
TM pure functions should not be inlined into non-TM_pure
functions. Don't inline if the callee can throw non-call exceptions but the
caller cannot.
FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is missing.
Move the flag into cgraph node or mirror it in the inline summary. Check compatibility of target optimization options.
Check if caller growth allows the inlining.
Don't inline a function with a higher optimization level than the
caller. FIXME: this is really just tip of iceberg of handling
optimization attribute. gcc.dg/pr43564.c. Look at forced inline even in -O0.
Referenced by update_caller_keys().
|
static |
Return true when NODE has uninlinable caller; set HAS_HOT_CALL if it has hot call. Worker for cgraph_for_node_and_aliases.
|
inline |
Same as compute_uinlined_call_time but compute time when inlining does happen.
Possible one roundoff error, but watch for overflows.
Referenced by has_caller_p().
|
static |
Given whole compilation unit estimate of INSNS, compute how large we can allow the unit to grow.
|
inline |
Compute time of the edge->caller + edge->callee execution when inlining does not happen.
Referenced by has_caller_p().
|
static |
Decide on the inlining. We do so in the topological order to avoid expenses on updating data structures.
Do not consider functions not declared inline.
|
static |
Do inlining of small functions. Doing so early helps profiling and other passes to be somewhat more effective and avoids some code duplication in later real inlining pass for testcases with very many function calls.
Do nothing if datastructures for ipa-inliner are already computed. This
happens when some pass decides to construct new function and
cgraph_add_new_function calls lowering passes and early optimization on
it. This may confuse ourself when early inliner decide to inline call to
function clone, because function clones don't have parameter list in
ipa-prop matching their signature. Even when not optimizing or not inlining inline always-inline
functions. Never inline regular functions into always-inline functions
during incremental inlining. This sucks as functions calling
always inline functions will get less optimized, but at the
same time inlining of functions calling always inline
function into an always inline function might introduce
cycles of edges to be always inlined in the callgraph.
We might want to be smarter and just avoid this type of inlining. When the function is marked to be flattened, recursively inline
all calls in it. We iterate incremental inlining to get trivial cases of indirect
inlining. Technically we ought to recompute inline parameters so the new
iteration of early inliner works as expected. We however have
values approximately right and thus we only need to update edge
info that might be cleared out for newly discovered edges.
|
static |
A cost model driving the inlining heuristics in a way so the edges with smallest badness are inlined first. After each inlining is performed the costs of all caller edges of nodes affected are recomputed so the metrics may accurately depend on values such as number of inlinable callers of the function or function body size.
Always prefer inlining saving code size.
When profiling is available, compute badness as:
relative_edge_count * relative_time_benefit
goodness = -------------------------------------------
growth_f_caller
badness = -goodness
The fraction is upside down, because on edge counts and time beneits
the bounds are known. Edge growth is essentially unlimited. Capping edge->count to max_count. edge->count can be larger than
max_count if an inline adds new edges which increase max_count
after max_count is computed. relative_edge_count.
relative_time_benefit.
growth_f_caller.
When function local profile is available. Compute badness as:
relative_time_benefit
goodness = ---------------------------------
growth_of_caller * overall_growth
badness = - goodness
compensated by the inline hints. When function local profile is not available or it does not give
useful information (ie frequency is zero), base the cost on
loop nest and overall size growth, so we optimize for overall number
of functions fully inlined in program. Decrease badness if call is nested.
Ensure that we did not overflow in all the fixed point math above.
Make recursive inlining happen always after other inlining is done.
References cgraph_edge::count, dump_file, max_count, relative_time_benefit(), sreal_div(), sreal_init(), sreal_mul(), and sreal_to_int().
|
static |
Flatten NODE. Performed both during early inlining and at IPA inlining time.
We shouldn't be called recursively when we are being processed.
We've hit cycle? It is time to give up.
When the edge is already inlined, we just need to recurse into
it in order to fully flatten the leaves. Flatten attribute needs to be processed during late inlining. For
extra code quality we however do flattening during early optimization,
too. Inline the edge and flatten the inline clone. Avoid
recursing through the original node if the node was cloned.
References cgraph_edge::caller, cgraph_node::callers, cgraph_node_name(), dump_file, cgraph_node::global, inline_call(), cgraph_global_info::inlined_to, and inline_summary::size.
|
static |
When to run IPA inlining. Inlining of always-inline functions happens during early inlining. Enable inlining unconditoinally, because callgraph redirection happens here.
|
static |
If NODE has a caller, return true.
References compute_inlined_call_time(), and compute_uninlined_call_time().
|
static |
Remove EDGE from the fibheap.
|
static |
Inline always-inline function calls in NODE.
Set inlined to true if the callee is marked "always_inline" but
is not inlinable. This will allow flagging an error later in
expand_call_inline in tree-inline.c.
|
static |
We use greedy algorithm for inlining of small functions: All inline candidates are put into prioritized heap ordered in increasing badness. The inlining of small functions is bounded by unit growth parameters.
Compute overall unit size and other global parameters used by badness
metrics. Populate the heeap with all edges we might inline.
Be sure that caches are maintained consistent.
We can not make this ENABLE_CHECKING only because it cause different
updates of the fibheap queue. When updating the edge costs, we only decrease badness in the keys.
Increases of badness are handled lazilly; when we see key with out
of date value on it, we re-insert it now. Heuristics for inlining small functions works poorly for
recursive calls where we do efect similar to loop unrolling.
When inliing such edge seems profitable, leave decision on
specific inliner. Recursive inliner inlines all recursive calls of the function
at once. Consequently we need to update all callee keys. Consider the case where self recursive function A is inlined into B.
This is desired optimization in some cases, since it leads to effect
similar of loop peeling and we might completely optimize out the
recursive call. However we must be extra selective. Our profitability metric can depend on local properties
such as number of inlinable calls and size of the function body.
After inlining these properties might change for the function we
inlined into (since it's body size changed) and for the functions
called by function we inlined (since number of it inlinable callers
might change).
References cgraph_edge::aux, and update_edge_key().
|
static |
Inline NODE to all callers. Worker for cgraph_for_node_and_aliases. DATA points to number of calls originally found so we avoid infinite recursion.
|
static |
Decide on the inlining. We do so in the topological order to avoid expenses on updating data structures.
In the first pass handle functions to be flattened. Do this with
a priority so none of our later choices will make this impossible. Handle nodes to be flattened.
Ideally when processing callees we stop inlining at the
entry of cycles, possibly cloning that entry point and
try to flatten itself turning it into a self-recursive
function. Do first after-inlining removal. We want to remove all "stale" extern inline
functions and virtual functions so we really know what is called once. Inline functions with a property that after inlining into all callers the
code size will shrink because the out-of-line copy is eliminated.
We do this regardless on the callee size as long as function growth limits
are met. Inlining one function called once has good chance of preventing
inlining other function into the same callee. Ideally we should
work in priority order, but probably inlining hot functions first
is good cut without the extra pain of maintaining the queue.
??? this is not really fitting the bill perfectly: inlining function
into callee often leads to better optimization of callee due to
increased context for optimization.
For example if main() function calls a function that outputs help
and then function that does the main optmization, we should inline
the second with priority even if both calls are cold by themselves.
We probably want to implement new predicate replacing our use of
maybe_hot_edge interpreted as maybe_hot_edge || callee is known
to be hot. Free ipa-prop structures if they are no longer needed.
In WPA we use inline summaries for partitioning process.
|
static |
Enqueue all recursive calls from NODE into priority queue depending on how likely we want to recursively inline the call.
When profile feedback is available, prioritize by expected number
of calls.
References cgraph_redirect_edge_callee(), and reset_edge_growth_cache().
| gimple_opt_pass* make_pass_early_inline | ( | ) |
| ipa_opt_pass_d* make_pass_ipa_inline | ( | ) |
|
static |
Return number of calls in N. Ignore cheap builtins.
References cgraph_edge::inline_failed, and report_inline_failed_reason().
|
static |
Decide on recursive inlining: in the case function has recursive calls, inline until body size reaches given argument. If any new indirect edges are discovered in the process, add them to *NEW_EDGES, unless NEW_EDGES is NULL.
Make sure that function is small enough to be considered for inlining.
Do the inlining and update list of recursive call during process.
MASTER_CLONE is produced in the case we already started modified
the function. Be sure to redirect edge to the original body before
estimating growths otherwise we will be seeing growths after inlining
the already modified body. We need original clone to copy around.
Remove master clone we used for inlining. We rely that clones inlined
into master clone gets queued just before master clone so we don't
need recursion.
References cgraph_redirect_edge_callee(), and reset_edge_growth_cache().
|
inlinestatic |
Return relative time improvement for inlining EDGE in range 1...RELATIVE_TIME_BENEFIT_RANGE
Inlining into extern inline function is not a win.
Watch overflows.
Compute relative time benefit, i.e. how much the call becomes faster.
??? perhaps computing how much the caller+calle together become faster
would lead to more realistic results.
Referenced by edge_badness().
|
static |
Dump info about why inlining has failed.
References cgraph_edge::callee, cgraph_edge::caller, cgraph_function_or_thunk_node(), symtab_node_base::decl, and inline_summary::inlinable.
Referenced by num_calls(), and update_caller_keys().
|
static |
NODE was inlined. All caller edges needs to be resetted because size estimates change. Similarly callees needs reset because better context may be known.
WHERE body size has changed, the cached growth is invalid.
Referenced by add_new_edges_to_heap().
|
static |
We know that EDGE is not going to be inlined. See if we can remove speculation.
| bool speculation_useful_p | ( | ) |
Return true if speculation of edge E seems useful. If ANTICIPATE_INLINING is true, be conservative and hope that E may get inlined.
See if IP optimizations found something potentially useful about the
function. For now we look only for CONST/PURE flags. Almost everything
else we propagate is useless. If we did not managed to inline the function nor redirect
to an ipa-cp clone (that are seen by having local flag set),
it is probably pointless to inline it unless hardware is missing
indirect call predictor. For overwritable targets there is not much to do.
OK, speculation seems interesting.
Referenced by add_new_edges_to_heap().
|
static |
Count number of callers of NODE and store it into DATA (that points to int. Worker for cgraph_for_node_and_aliases.
|
static |
Recompute HEAP nodes for each uninlined call in NODE. This is used when we know that edge badnesses are going only to increase (we introduced new call site) and thus all we need is to insert newly created edges into heap.
We do not reset callee growth cache here. Since we added a new call,
growth chould have just increased and consequentely badness metric
don't need updating.
|
static |
Recompute HEAP nodes for each of caller of NODE. UPDATED_NODES track nodes we already visited, to avoid redundant work. When CHECK_INLINABLITY_FOR is set, re-check for specified edge that it is inlinable. Otherwise check all edges.
References cgraph_edge::aux, can_inline_edge_p(), report_inline_failed_reason(), update_edge_key(), and want_inline_small_function_p().
Referenced by add_new_edges_to_heap().
|
inlinestatic |
Recompute badness of EDGE and update its key in HEAP if needed.
fibheap_replace_key only decrease the keys.
When we increase the key we do not update heap
and instead re-insert the element once it becomes
a minimum of heap.
Referenced by inline_small_functions(), and update_caller_keys().
|
static |
Return true if we are interested in inlining small function.
References cgraph_edge::caller, cgraph_node_name(), dump_file, and symtab_node_base::order.
|
static |
Decide if inlining NODE would reduce unit size by eliminating the offline copy of function. When COLD is true the cold calls are considered, too.
Does it have callers?
Already inlined?
Inlining into all callers would increase size?
All inlines must be possible.
|
static |
EDGE is self recursive edge. We hand two cases - when function A is inlining into itself or when function A is being inlined into another inliner copy of function A within function B. In first case OUTER_NODE points to the toplevel copy of A, while in the second case OUTER_NODE points to the outermost copy of A in B. In both cases we want to be extra selective since inlining the call will just introduce new recursive calls to appear.
Inlining of self recursive function into copy of itself within other function
is transformation similar to loop peeling.
Peeling is profitable if we can inline enough copies to make probability
of actual call to the self recursive function very small. Be sure that
the probability of recursion is small.
We ensure that the frequency of recursing is at most 1 - (1/max_depth).
This way the expected number of recision is at most max_depth. Recursive inlining, i.e. equivalent of unrolling, is profitable if recursion
depth is large. We reduce function call overhead and increase chances that
things fit in hardware return predictor.
Recursive inlining might however increase cost of stack frame setup
actually slowing down functions whose recursion tree is wide rather than
deep.
Deciding reliably on when to do recursive inlining without profile feedback
is tricky. For now we disable recursive inlining when probability of self
recursion is low.
Recursive inlining of self recursive call within loop also results in large loop
depths that generally optimize badly. We may want to throttle down inlining
in those cases. In particular this seems to happen in one of libstdc++ rb tree
methods.
References cgraph_node::count, cgraph_edge::count, cgraph_edge::frequency, and max_count.
|
static |
Return true if we are interested in inlining small function. When REPORT is true, report reason to dump file.
Apply MAX_INLINE_INSNS_SINGLE limit. Do not do so when
hints suggests that inlining given function is very profitable. Before giving up based on fact that caller size will grow, allow
functions that are called few times and eliminating the offline
copy will lead to overall code size reduction.
Not all of these will be handled by subsequent inlining of functions
called once: in particular weak functions are not handled or funcitons
that inline to multiple calls but a lot of bodies is optimized out.
Finally we want to inline earlier to allow inlining of callbacks.
This is slightly wrong on aggressive side: it is entirely possible
that function is called many times with a context where inlining
reduces code size and few times with a context where inlining increase
code size. Resoluting growth estimate will be negative even if it
would make more sense to keep offline copy and do not inline into the
call sites that makes the code size grow.
When badness orders the calls in a way that code reducing calls come
first, this situation is not a problem at all: after inlining all
"good" calls, we will realize that keeping the function around is
better. Unlike for functions called once, we play unsafe with
COMDATs. We can allow that since we know functions
in consideration are small (and thus risk is small) and
moreover grow estimates already accounts that COMDAT
functions may or may not disappear when eliminated from
current unit. With good probability making aggressive
choice in all units is going to make overall program
smaller.
Consequently we ask cgraph_can_remove_if_no_direct_calls_p
instead of
cgraph_will_be_removed_from_program_if_no_direct_calls Apply MAX_INLINE_INSNS_AUTO limit for functions not declared inline
Upgrade it to MAX_INLINE_INSNS_SINGLE when hints suggests that
inlining given function is very profitable. If call is cold, do not inline when function body would grow.
References cgraph_edge::inline_failed.
Referenced by update_caller_keys().
|
static |
|
static |
Referenced by edge_badness(), and want_inline_self_recursive_call_p().
|
static |
|
static |
|
static |
@verbatim
Inlining decision heuristics. Copyright (C) 2003-2013 Free Software Foundation, Inc. Contributed by Jan Hubicka
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.
GCC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/.
Inlining decision heuristics
The implementation of inliner is organized as follows:
inlining heuristics limits
can_inline_edge_p allow to check that particular inlining is allowed
by the limits specified by user (allowed function growth, growth and so
on).
Functions are inlined when it is obvious the result is profitable (such
as functions called once or when inlining reduce code size).
In addition to that we perform inlining of small functions and recursive
inlining.
inlining heuristics
The inliner itself is split into two passes:
pass_early_inlining
Simple local inlining pass inlining callees into current function.
This pass makes no use of whole unit analysis and thus it can do only
very simple decisions based on local properties.
The strength of the pass is that it is run in topological order
(reverse postorder) on the callgraph. Functions are converted into SSA
form just before this pass and optimized subsequently. As a result, the
callees of the function seen by the early inliner was already optimized
and results of early inlining adds a lot of optimization opportunities
for the local optimization.
The pass handle the obvious inlining decisions within the compilation
unit - inlining auto inline functions, inlining for size and
flattening.
main strength of the pass is the ability to eliminate abstraction
penalty in C++ code (via combination of inlining and early
optimization) and thus improve quality of analysis done by real IPA
optimizers.
Because of lack of whole unit knowledge, the pass can not really make
good code size/performance tradeoffs. It however does very simple
speculative inlining allowing code size to grow by
EARLY_INLINING_INSNS when callee is leaf function. In this case the
optimizations performed later are very likely to eliminate the cost.
pass_ipa_inline
This is the real inliner able to handle inlining with whole program
knowledge. It performs following steps:
1) inlining of small functions. This is implemented by greedy
algorithm ordering all inlinable cgraph edges by their badness and
inlining them in this order as long as inline limits allows doing so.
This heuristics is not very good on inlining recursive calls. Recursive
calls can be inlined with results similar to loop unrolling. To do so,
special purpose recursive inliner is executed on function when
recursive edge is met as viable candidate.
2) Unreachable functions are removed from callgraph. Inlining leads
to devirtualization and other modification of callgraph so functions
may become unreachable during the process. Also functions declared as
extern inline or virtual functions are removed, since after inlining
we no longer need the offline bodies.
3) Functions called once and not exported from the unit are inlined.
This should almost always lead to reduction of code size by eliminating
the need for offline copy of the function. Statistics we collect about inlining algorithm.
1.8.1.1