Collaboration diagram for iv_to_split:

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

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.