public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: Wolfgang Bangerth <wolfgang.bangerth@iwr.uni-heidelberg.de>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	gcc-patches@gcc.gnu.org
Subject: Re: Loop unroll fixes
Date: Wed, 10 Oct 2001 05:14:00 -0000	[thread overview]
Message-ID: <5.1.0.14.2.20011010134053.04e57e78@mail.lauterbach.com> (raw)
In-Reply-To: <36070000.1002701777@warlock.codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

At 10:16 10.10.2001, Mark Mitchell wrote:


>--On Wednesday, October 10, 2001 10:12:38 AM +0200 Wolfgang Bangerth 
><wolfgang.bangerth@iwr.uni-heidelberg.de> wrote:
>
>>
>>>I anticipate those being the last changes for GCC 3.0.2.
>>
>>Not arguing for this just because it happened to bite me, but it might be
>>worth to also look at c++/4512, which is a regression w.r.t. 3.0.1. Franz
>>said he'll look into it.
>
>Thank you for pointing this out.  We need to identify this problem, fix
>it, or remove the patch that is causing it.  Regressions from previous
>3.0 releases are very, very bad.

I already tracked down what's happening and produced a simple fix. 
Bootstrapped and regtested on x86 so far.

The problem here is that if a loop gets unrolled, the uid_luid array 
doesn't get updated. In the testcase the loop getting unrolled is part of 
the loop exit tests of another loop. So when the loop exit insns are 
scanned as in the last change to loop_iterations, we get an abort as soon 
as we hit an insn that was generated by loop unrolling :-(.

Probably the cleanest solution would be to recalculate uid_luid after each 
call to scan_loop. Since this wasn't done so far, I guess this has either 
compile time impacts or would confuse other parts of the loop code.
Fortunately, in this case we can just ignore the insns generated by loop 
unrolling, cause they will contain the same insns than the original loop 
body and it's enough if we test for back edges only in the original ones.

So I suggest the appended patch.

OK to commit?

Franz.

         PR c++/4512
         * unroll.c (loop_iterations): Ignore insns generated by loop 
unrolling.


[-- Attachment #2: gcc3-loop-2.patch --]
[-- Type: text/x-diff, Size: 668 bytes --]

Index: gcc/unroll.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/unroll.c,v
retrieving revision 1.125.4.2
diff -u -p -r1.125.4.2 unroll.c
--- gcc/unroll.c	2001/10/08 21:33:16	1.125.4.2
+++ gcc/unroll.c	2001/10/10 12:08:05
@@ -3506,6 +3523,11 @@ loop_iterations (loop)
 
       do
 	{
+	  /* Previous unrolling may have generated new insns not covered
+	     by the uid_luid array.  */
+	  if (INSN_UID (temp) >= max_uid_for_loop)
+	    continue;
+
 	  if (GET_CODE (temp) == JUMP_INSN
 	      && INSN_LUID (JUMP_LABEL (temp)) > INSN_LUID (loop->top)
 	      && INSN_LUID (JUMP_LABEL (temp)) < INSN_LUID (loop->cont))

  reply	other threads:[~2001-10-10  5:14 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-10  1:12 Wolfgang Bangerth
2001-10-10  1:16 ` Mark Mitchell
2001-10-10  5:14   ` Franz Sirl [this message]
2001-10-10 11:08     ` Mark Mitchell
  -- strict thread matches above, loose matches on Subject: below --
2001-09-18 17:36 Richard Kenner
2001-09-18 11:54 mike stump
2001-09-18 12:34 ` Joseph S. Myers
2001-09-19 11:28   ` Joe Buck
2001-09-24  9:31     ` law
2001-09-18 10:47 Benjamin Kosnik
2001-09-18  4:16 Richard Kenner
     [not found] <200109142021.QAA26236@makai.watson.ibm.com>
2001-09-15  8:57 ` Bernd Schmidt
2001-09-17 13:16   ` Richard Henderson
2001-09-17 14:24     ` Joe Buck
2001-09-17 15:11       ` Richard Henderson
2001-09-17 17:22         ` Mark Mitchell
2001-09-18  2:19         ` Joseph S. Myers
     [not found] <Pine.LNX.4.33.0109141957550.29416-100000@host140.cambridge.redhat.com>
2001-09-14 14:36 ` David Edelsohn
2001-09-13 16:35 Zoltan Hidvegi
2001-09-13 18:58 ` David Edelsohn
2001-09-13 23:50   ` Jim Wilson
2001-09-14  6:55     ` Daniel Berlin
2001-09-14 12:15       ` Joseph S. Myers
2001-09-14 16:45       ` Jim Wilson
2001-09-14 20:11         ` David Edelsohn
2001-09-14 22:23           ` Jim Wilson
2001-09-15  2:42           ` Bernd Schmidt
2001-09-14 21:16         ` Daniel Berlin
2001-09-14  9:41     ` David Edelsohn
2001-09-14 10:46       ` Bernd Schmidt
2001-09-14 11:47         ` David Edelsohn
2001-09-14 17:54       ` Jim Wilson
2001-09-14 18:35         ` David Edelsohn
2001-09-14 19:56           ` Jim Wilson
2001-09-15  2:56         ` Joseph S. Myers
2001-10-04  6:46 ` Franz Sirl
2001-10-04  7:40   ` Mark Mitchell
2001-10-04 20:46   ` Jim Wilson
2001-10-04 20:51     ` Mark Mitchell
2001-10-04 23:10       ` Zoltan Hidvegi
2001-10-10  0:05         ` Mark Mitchell

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=5.1.0.14.2.20011010134053.04e57e78@mail.lauterbach.com \
    --to=franz.sirl-kernel@lauterbach.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    --cc=wolfgang.bangerth@iwr.uni-heidelberg.de \
    /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).