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/27883] [4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
Date: Tue, 27 Jun 2006 03:03:00 -0000	[thread overview]
Message-ID: <20060627030241.31930.qmail@sourceware.org> (raw)
In-Reply-To: <bug-27883-12387@http.gcc.gnu.org/bugzilla/>



------- Comment #4 from wilson at gcc dot gnu dot org  2006-06-27 03:02 -------
This only fails for --enable-checking builds, which is the default for
mainline, but not release branches.  I was able to reproduce this with gcc-4.0,
but not gcc-3.4.  The difference between the two is that gcc-4.0 has the
__builtin_copysign support, which emits the RTL that triggers the error.  The
error has probably been latent for a while.

The insn that causes the problem is
(jump_insn 99 98 113 15 (set (pc)
        (if_then_else (ge:SI (subreg:SI (reg:DF 32 $f0) 4)
                (const_int 0 [0x0]))
            (label_ref 101)
            (pc))) 261 {*branch_zerosi} (insn_list:REG_DEP_TRUE 94 (nil))
    (expr_list:REG_DEAD (reg:SI 33 $f1)
        (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
            (nil))))
On a 32-bit mips target, DFmode $f0 is a register pair $f0/$f1, so technically
this is correct.  There is a corresponding REG_UNUSED for $f0 on the insn that
sets (reg:DF 32 $f0).

However, flow doesn't track individual regs in subregs, it only tracks the
whole subreg.  Note that mark_used_reg ignores subregs.  So when we execute the
second life pass, we end up with
(jump_insn 98 97 112 17 (set (pc)
        (if_then_else (ge (subreg:SI (reg:DF 32 $f0) 4)
                (const_int 0 [0x0]))
            (label_ref 100)
            (pc))) 271 {*branch_ordersi} (insn_list:REG_DEP_TRUE 93 (nil))
    (expr_list:REG_DEAD (reg:DF 32 $f0)
        (expr_list:REG_DEAD (reg:SI 33 $f1)
            (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
                (nil)))))
Note that we now have two overlapping REG_DEAD notes plus an overlapping
REG_UNUSED note on a previous insn.  When sched runs, it deletes both REG_DEAD
notes, but only readds one, resulting in the abort for a REG_DEAD note
consistency problem.

A subreg of a hard register is normally not allowed, but it is created in this
case because CANNOT_CHANGE_CLASS_MODE is defined, and HARD_REGNO_MODE_OK says
that an SImode $f1 is not OK.  The result is that simplify_subreg doesn't
simplify this.  The other part is that register_operand says it is OK. 
Eventually, this gets fixed by reload.

Fixing combine to get this right looks complicated.  Combine has to know that
the register was used inside a subreg, and then figure out that the subreg
wasn't simplified because of CANNOT_CHANGE_CLASS_MODE, etc.

I think a simpler solution here is to note that the life2 pass would have
worked correctly if it deleted all prior REG_UNUSED/REG_DEAD notes before it
started.  Incidentally, the comments for the life2 pass say it was explicitly
added to fix REG_UNUSED/REG_DEAD problems with distribute_notes in combine, so
it was apparently added to fix a related problem.  It just isn't working the
way it was originally intended.

It is curious that life2 is running immediately before sched, instead of
immediately after combine.  If we ran it immediately after combine, we could
get rid of the REG_DEAD/REG_UNUSED support in distribute_notes, which is
probably the most complicated, and most buggy, part of combine.  This would
also speed up the compiler a little bit.


-- 

wilson at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-27 03:02:40
               date|                            |


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


  parent reply	other threads:[~2006-06-27  3:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-03 14:42 [Bug target/27883] New: " tbm at cyrius dot com
2006-06-03 14:44 ` [Bug target/27883] " tbm at cyrius dot com
2006-06-03 16:01 ` pinskia at gcc dot gnu dot org
2006-06-04 19:50 ` mmitchel at gcc dot gnu dot org
2006-06-07 15:39 ` mkuvyrkov at gcc dot gnu dot org
2006-06-27  3:03 ` wilson at gcc dot gnu dot org [this message]
2006-06-27  3:20 ` [Bug target/27883] [4.0/4.1/4.2 " pinskia at gcc dot gnu dot org
2006-07-11  1:32 ` wilson at gcc dot gnu dot org
2006-07-11  1:42 ` wilson at gcc dot gnu dot org
2006-07-22 21:15 ` echristo at apple dot com
2006-07-22 22:07 ` pinskia at gcc dot gnu dot org
2006-07-24 19:34 ` wilson at tuliptree dot org
2006-08-23 18:56 ` tbm at gcc dot gnu dot org
2006-08-23 21:25 ` wilson at specifix dot com
2006-08-25 19:06 ` tbm at cyrius dot com
2006-08-25 20:10 ` tbm at cyrius dot com
2006-08-27 13:20 ` tbm at cyrius dot com
2006-09-07  4:24 ` [Bug rtl-optimization/27883] " pinskia at gcc dot gnu dot org
2006-09-07  4:25 ` [Bug rtl-optimization/27883] [4.0/4.1 " pinskia at gcc dot gnu dot org
2006-10-31 14:35 ` amylaar at gcc dot gnu dot org
2007-01-24 11:31 ` ebotcazou at gcc dot gnu dot org
2007-01-24 12:01 ` tbm at gcc dot gnu dot org
2007-02-10 15:18 ` ebotcazou at gcc dot gnu 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=20060627030241.31930.qmail@sourceware.org \
    --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).