Data Fields | |
| rtx | insn |
| rtx | orig_var |
| rtx | base_var |
| rtx | step |
| struct iv_to_split * | next |
| unsigned | n_loc |
| unsigned | loc [3] |
Detailed Description
@verbatim
Loop unrolling and peeling. Copyright (C) 2002-2013 Free Software Foundation, Inc.
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/.
This pass performs loop unrolling and peeling. We only perform these
optimizations on innermost loops (with single exception) because
the impact on performance is greatest here, and we want to avoid
unnecessary code size growth. The gain is caused by greater sequentiality
of code, better code to optimize for further passes and in some cases
by fewer testings of exit conditions. The main problem is code growth,
that impacts performance negatively due to effect of caches.
What we do:
-- complete peeling of once-rolling loops; this is the above mentioned
exception, as this causes loop to be cancelled completely and
does not cause code growth
-- complete peeling of loops that roll (small) constant times.
-- simple peeling of first iterations of loops that do not roll much
(according to profile feedback)
-- unrolling of loops that roll constant times; this is almost always
win, as we get rid of exit condition tests.
-- unrolling of loops that roll number of times that we can compute
in runtime; we also get rid of exit condition tests here, but there
is the extra expense for calculating the number of iterations
-- simple unrolling of remaining loops; this is performed only if we
are asked to, as the gain is questionable in this case and often
it may even slow down the code
For more detailed descriptions of each of those, see comments at
appropriate function below.
There is a lot of parameters (defined and described in params.def) that
control how much we unroll/peel.
??? A great problem is that we don't have a good way how to determine
how many times we should unroll the loop; the experiments I have made
showed that this choice may affect performance in order of several %. Information about induction variables to split.
Field Documentation
| rtx iv_to_split::base_var |
Referenced by analyze_insn_to_expand_var().
| rtx iv_to_split::insn |
Referenced by analyze_insn_to_expand_var(), and iv_split_hasher::hash().
| unsigned iv_to_split::loc[3] |
Referenced by analyze_insn_to_expand_var().
| unsigned iv_to_split::n_loc |
Referenced by analyze_insn_to_expand_var().
| struct iv_to_split* iv_to_split::next |
Referenced by analyze_insn_to_expand_var(), and expand_var_during_unrolling().
| rtx iv_to_split::orig_var |
Referenced by analyze_insn_to_expand_var(), and expand_var_during_unrolling().
| rtx iv_to_split::step |
Referenced by analyze_insn_to_expand_var().
The documentation for this struct was generated from the following file:
