public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "wilson at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/13877] [3.3 regression] miscompilation with -O -funroll-loops on powerpc
Date: Wed, 10 Mar 2004 23:43:00 -0000	[thread overview]
Message-ID: <20040310234313.11436.qmail@sources.redhat.com> (raw)
In-Reply-To: <20040127073741.13877.debian-gcc@lists.debian.org>


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


  parent reply	other threads:[~2004-03-10 23:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-27  7:37 [Bug target/13877] New: " debian-gcc at lists dot debian dot org
2004-01-27  7:38 ` [Bug target/13877] " debian-gcc at lists dot debian dot org
2004-01-27  7:44 ` pinskia at gcc dot gnu dot org
2004-01-27  8:25 ` pinskia at gcc dot gnu dot org
2004-02-15 12:41 ` gdr at gcc dot gnu dot org
2004-03-05 11:38 ` gdr at gcc dot gnu dot org
2004-03-05 22:08 ` doko at cs dot tu-berlin dot de
2004-03-10 23:43 ` wilson at gcc dot gnu dot org [this message]
2004-03-13  1:19 ` cvs-commit at gcc dot gnu dot org
2004-03-13  1:20 ` gdr at gcc dot gnu dot org
2004-03-13  7:04 ` debian-gcc at lists dot debian dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040310234313.11436.qmail@sources.redhat.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).