Collaboration diagram for iv_to_split:

[legend]

Data Fields
rtx_insn *	insn

rtx	orig_var

rtx	base_var

rtx	step

struct iv_to_split *	next

Detailed Description

Loop unrolling.
   Copyright (C) 2002-2024 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.  We only perform this
optimization 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:

-- 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.

??? 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

◆ base_var

rtx iv_to_split::base_var

Referenced by allocate_basic_variable(), analyze_iv_to_split_insn(), insert_base_initialization(), and split_iv().

◆ insn

rtx_insn* iv_to_split::insn

Referenced by allocate_basic_variable(), analyze_iv_to_split_insn(), apply_opt_in_copies(), iv_split_hasher::hash(), and maybe_strip_eq_note_for_split_iv().

◆ next

struct iv_to_split* iv_to_split::next

Referenced by analyze_insns_in_loop(), analyze_iv_to_split_insn(), apply_opt_in_copies(), and maybe_strip_eq_note_for_split_iv().

◆ orig_var

rtx iv_to_split::orig_var

Referenced by analyze_iv_to_split_insn(), and maybe_strip_eq_note_for_split_iv().

◆ step

rtx iv_to_split::step

Referenced by analyze_iv_to_split_insn(), and split_iv().

The documentation for this struct was generated from the following file:

loop-unroll.cc