help-rcs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug target/13877] [3.3 regression] miscompilation with -O -funroll-loop


From: wilson at gcc dot gnu dot org
Subject: [Bug target/13877] [3.3 regression] miscompilation with -O -funroll-loops on powerpc
Date: 10 Mar 2004 23:43:13 -0000

------- Additional Comments From wilson at gcc dot gnu dot org  2004-03-10 
23:43 -------
I can reproduce the problem with gcc-3_3-branch on powerpc-darwin.  I can also
reproduce the problem with current sources using -O -fold-unroll-loops.

The problem is a bad interaction between the old loop unroller and doloop.  The
loop in question executes 6 times.  The initial value of the iterator is 0.  The
final value is pseudo-reg 118 which holds the value 6 at run time.  The old loop
unrolling preconditions the loop and then unrolls it four times.  Now, at the
LOOP_BEG note, the initial value is now 2 at runtime, or (mod (reg 118)
(const_int 4)).  The loop_info->initial_value field is not changed.

Then doloop_optimize runs, and tries to do some of the same calculations as
unroll.c.  It decides that the loop will run (reg 118) times (i.e. 6 times),
because that is final_value minus the initial_value.  It sees that the loop
increments the iterator by 4 each loop iteration, and thus the loop must execute
ceil (r118 / 4) * 4, which at run time means 8.  And now we are hosed, as doloop
proceeds to make incorrect transformations based on the 8 number.

One possible way to fix this is to clear loop_info->initial_value after
preconditioning the loop, to indicate that the initial value is now unknown. 
This disables the doloop optimization, avoiding the bug.  Putting the (mod...)
expression here seems less useful, as that might confuse other loop optimizers.

An even better solution would be to pass enough info from unroll_loops to
do_loop_optimize so that the optimization can still occur.  I haven't looked at
how to do this.

This problem does not occur with the new loop unroller because it is a separate
pass from loop.c, and does not use the loop_info structure.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-03-10 23:43:10
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13877




reply via email to

[Prev in Thread] Current Thread [Next in Thread]