Weights that estimate_num_insns uses to estimate the size of the produced code.
Tree inlining. Copyright (C) 2001-2013 Free Software Foundation, Inc. Contributed by Alexandre Oliva aoliv.nosp@m.a@re.nosp@m.dhat..nosp@m.com
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/. I'm not real happy about this, but we need to handle gimple and non-gimple trees. Inlining, Cloning, Versioning, Parallelization
Inlining: a function body is duplicated, but the PARM_DECLs are remapped into VAR_DECLs, and non-void RETURN_EXPRs become MODIFY_EXPRs that store to a dedicated returned-value variable. The duplicated eh_region info of the copy will later be appended to the info for the caller; the eh_region info in copied throwing statements and RESX statements are adjusted accordingly.
Cloning: (only in C++) We have one body for a con/de/structor, and multiple function decls, each with a unique parameter list. Duplicate the body, using the given splay tree; some parameters will become constants (like 0 or 1).
Versioning: a function body is duplicated and the result is a new function rather than into blocks of an existing function as with inlining. Some parameters will become constants.
Parallelization: a region of a function is duplicated resulting in a new function. Variables may be replaced with complex expressions to enable shared variable semantics.
All of these will simultaneously lookup any callgraph edges. If we're going to inline the duplicated function body, and the given function has some cloned callgraph nodes (one for each place this function will be inlined) those callgraph edges will be duplicated. If we're cloning the body, those callgraph edges will be updated to point into the new body. (Note that the original callgraph node and edge list will not be altered.)
See the CALL_EXPR handling case in copy_tree_body_r (). To Do:
o In order to make inlining-on-trees work, we pessimized function-local static constants. In particular, they are now always output, even when not addressed. Fix this by treating function-local static constants just like global static constants; the back-end already knows not to output them if they are not needed.
o Provide heuristics to clamp inlining of recursive template calls? Weights that estimate_num_insns uses to estimate the size of the produced code.
Referenced by count_insns(), and tree_ssa_unswitch_loops().