GCC Middle and Back End API Reference
loop-doloop.c File Reference


rtx doloop_condition_get ()
static bool doloop_valid_p ()
static bool add_test ()
static void doloop_modify (struct loop *loop, struct niter_desc *desc, rtx doloop_seq, rtx condition, rtx count)
static bool doloop_optimize ()
void doloop_optimize_loops ()

Function Documentation

static bool add_test ( )
   Adds test of COND jumping to DEST on edge *E and set *E to the new fallthru
   edge.  If the condition is always false, do not do anything.  If it is always
   true, redirect E to DEST and return false.  In all other cases, true is
         The condition is always false and the jump was optimized out.  
     There always is at least the jump insn in the sequence.  
         The condition is always true.  
     The jump is supposed to handle an unlikely special case.  

References end_sequence().

rtx doloop_condition_get ( )

Perform doloop optimizations Copyright (C) 2004-2013 Free Software Foundation, Inc. Based on code by Michael P. Hayes (m.hay.nosp@m.es@e.nosp@m.lec.c.nosp@m.ante.nosp@m.rbury.nosp@m..ac..nosp@m.nz)

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 module is used to modify loops with a determinable number of
   iterations to use special low-overhead looping instructions.

   It first validates whether the loop is well behaved and has a
   determinable number of iterations (either at compile or run-time).
   It then modifies the loop to use a low-overhead looping pattern as

   1. A pseudo register is allocated as the loop iteration counter.

   2. The number of loop iterations is calculated and is stored
      in the loop counter.

   3. At the end of the loop, the jump insn is replaced by the
      doloop_end pattern.  The compare must remain because it might be
      used elsewhere.  If the loop-variable or condition register are
      used elsewhere, they will be eliminated by flow.

   4. An optional doloop_begin pattern is inserted at the top of the

   TODO The optimization should only performed when either the biv used for exit
   condition is unused at all except for the exit test, or if we do not have to
   change its value, since otherwise we have to add a new induction variable,
   which usually will not pay up (unless the cost of the doloop pattern is
   somehow extremely lower than the cost of compare & jump, or unless the bct
   register cannot be used for anything else but doloop -- ??? detect these
   Return the loop termination condition for PATTERN or zero
   if it is not a decrement and branch jump insn.  
     The canonical doloop pattern we expect has one of the following

     1)  (parallel [(set (pc) (if_then_else (condition)
                                            (label_ref (label))
                     (set (reg) (plus (reg) (const_int -1)))
                     (additional clobbers and uses)])

     The branch must be the first entry of the parallel (also required
     by jump.c), and the second entry of the parallel must be a set of
     the loop counter register.  Some targets (IA-64) wrap the set of
     the loop counter in an if_then_else too.

     2)  (set (reg) (plus (reg) (const_int -1))
         (set (pc) (if_then_else (reg != 0)
                                 (label_ref (label))

     Some targets (ARM) do the comparison before the branch, as in the
     following form:

     3) (parallel [(set (cc) (compare ((plus (reg) (const_int -1), 0)))
                   (set (reg) (plus (reg) (const_int -1)))])
        (set (pc) (if_then_else (cc == NE)
                                (label_ref (label))
         In case the pattern is not PARALLEL we expect two forms
         of doloop which are cases 2) and 3) above: in case 2) the
         decrement immediately precedes the branch, while in case 3)
         the compare and decrement instructions immediately precede
         the branch.  
             The third case: the compare and decrement instructions
             immediately precede the branch.  
         We expect the condition to be of the form (reg != 0)  
     Check for (set (reg) (something)).  
     Check if something = (plus (reg) (const_int -1)).
     On IA-64, this decrement is wrapped in an if_then_else.  
     Check for (set (pc) (if_then_else (condition)
                                       (label_ref (label))
     Extract loop termination condition.  
     We expect a GE or NE comparison with 0 or 1.  
         For the third case:  
         For the second form we expect:

         (set (reg) (plus (reg) (const_int -1))
         (set (pc) (if_then_else (reg != 0)
                                 (label_ref (label))

         is equivalent to the following:

         (parallel [(set (pc) (if_then_else (reg != 1)
                                            (label_ref (label))
                     (set (reg) (plus (reg) (const_int -1)))
                     (additional clobbers and uses)])

        For the third form we expect:

        (parallel [(set (cc) (compare ((plus (reg) (const_int -1)), 0))
                   (set (reg) (plus (reg) (const_int -1)))])
        (set (pc) (if_then_else (cc == NE)
                                (label_ref (label))

        which is equivalent to the following:

        (parallel [(set (cc) (compare (reg,  1))
                   (set (reg) (plus (reg) (const_int -1)))
                   (set (pc) (if_then_else (NE == cc)
                                           (label_ref (label))

        So we return the second form instead for the two cases.
     ??? If a machine uses a funny comparison, we could return a
     canonicalized form here.  
static void doloop_modify ( struct loop loop,
struct niter_desc desc,
rtx  doloop_seq,
rtx  condition,
rtx  count 
   Modify the loop to use the low-overhead looping insn where LOOP
   describes the loop, DESC describes the number of iterations of the
   loop, and DOLOOP_INSN is the low-overhead looping insn to emit at the
   end of the loop.  CONDITION is the condition separated from the
   DOLOOP_SEQ.  COUNT is the number of iterations of the LOOP.  
     Get the probability of the original branch. If it exists we would
     need to update REG_BR_PROB of the new jump_insn.  
     Discard original jump to continue loop.  The original compare
     result may still be live, so it cannot be discarded explicitly.  
         Currently only NE tests against zero and one are supported.  
         Currently only GE tests against zero are supported.  
         The iteration count does not need incrementing for a GE test.  
         Determine if the iteration counter will be non-negative.
         Note that the maximum value loaded is iterations_max - 1.  
         Abort if an invalid doloop pattern has been generated.  
     Insert initialization of the count register into the loop header.  
         Expand the condition testing the assumptions and if it does not pass,
         reset the count register to 0.  
             We reached a condition that is always true.  This is very hard to
             reproduce (such a loop does not roll, and thus it would most
             likely get optimized out by some of the preceding optimizations).
             In fact, I do not have any testcase for it.  However, it would
             also be very hard to show that it is impossible, so we must
             handle this case.  
             All the conditions were simplified to false, remove the
             unreachable set_zero block.  
             Reset the counter to zero in the set_zero block.  
     Some targets (eg, C4x) need to initialize special looping
     Insert the new low-overhead looping insn.  
     Ensure the right fallthru edge is marked, for case we have reversed
     the condition.  
     Add a REG_NONNEG note if the actual or estimated maximum number
     of iterations is non-negative.  
     Update the REG_BR_PROB note.  
         Seems safer to use the branch probability.  
static bool doloop_optimize ( )
   Process loop described by LOOP validating that the loop is suitable for
   conversion to use a low overhead looping instruction, replacing the jump
   insn where suitable.  Returns true if the loop was successfully
     Find the simple exit of a LOOP.  
     Check that loop is a candidate for a low-overhead looping insn.  
     If the estimate on number of iterations is reliable (comes from profile
     feedback), use it.  Do not use it normally, since the expected number
     of iterations of an unrolled loop is 2.  
     Generate looping insn.  If the pattern FAILs then give up trying
     to modify the loop since there is some aspect the back-end does
     not like.  
         Before trying mode different from the one in that # of iterations is
         computed, we must be sure that the number of iterations fits into
         the new mode.  
     If multiple instructions were created, the last must be the
     jump instruction.  Also, a raw define_insn may yield a plain

References dump_file.

void doloop_optimize_loops ( void  )
   This is the main entry point.  Process all loops using doloop_optimize.  
static bool doloop_valid_p ( )
   Return nonzero if the loop specified by LOOP is suitable for
   the use of special low-overhead looping instructions.  DESC
   describes the number of iterations of the loop.  
     Check for loops that may not terminate under special conditions.  
         There are some cases that would require a special attention.
         For example if the comparison is LEU and the comparison value
         is UINT_MAX then the loop will not terminate.  Similarly, if the
         comparison code is GEU and the comparison value is 0, the
         loop will not terminate.

         If the absolute increment is not 1, the loop can be infinite
         even with LTU/GTU, e.g. for (i = 3; i > 0; i -= 2)

         ??? We could compute these conditions at run-time and have a
         additional jump around the loop to ensure an infinite loop.
         However, it is very unlikely that this is the intended
         behavior of the loop and checking for these rare boundary
         conditions would pessimize all other code.

         If the loop is executed only a few times an extra check to
         restart the loop could use up most of the benefits of using a
         count register loop.  Note however, that normally, this
         restart branch would never execute, so it could be predicted
         well by the CPU.  We should generate the pessimistic code by
         default, and have an option, e.g. -funsafe-loops that would
         enable count-register loops in this case.  
             Different targets have different necessities for low-overhead
             looping.  Call the back end for each instruction within the loop
             to let it decide whether the insn prohibits a low-overhead loop.
             It will then return the cause for it to emit to the dump file.