public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Zack Weinberg <zack@codesourcery.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE Date: Wed, 26 Mar 2003 20:46:00 -0000 [thread overview] Message-ID: <20030326203600.15742.qmail@sources.redhat.com> (raw) The following reply was made to PR optimization/10024; it has been noted by GNATS. From: Zack Weinberg <zack@codesourcery.com> To: Jan Hubicka <jh@suse.cz> Cc: gcc-gnats@gcc.gnu.org, tausq@debian.org Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE Date: Wed, 26 Mar 2003 12:26:16 -0800 > > In 3.4 something different is happening -- we get a verify_flow_info > failure, and this code path is never taken. I will continue looking. Jan, for background, this is an ICE caused by basic block reordering having mangled the flow graph. When reorder_basic_blocks is called, we have these basic blocks: ;; Basic block 13, loop depth 0, count 0 ;; Predecessors: 12 [100.0%] (fallthru) 7 [100.0%] 4 [100.0%] ;; Registers live at start: 2 [%r2] 20 [%r20] 30 [%r30] (code_label 159 262 236 13 13 "" [2 uses]) (note 236 159 162 13 [bb 13] NOTE_INSN_BASIC_BLOCK) (note 162 236 180 13 NOTE_INSN_DELETED) (jump_insn 180 162 186 13 0x4001b65c (parallel [ (set (pc) (if_then_else (ge (reg/v:SI 20 %r20 [orig:123 <anonymous> ] [123]) (const_int 0 [0x0])) (label_ref 186) (pc))) (set (reg/v:SI 28 %r28 [orig:104 <anonymous> ] [104]) (reg/v:SI 20 %r20 [orig:123 <anonymous> ] [123])) ]) 232 {*pa.md:7408} (nil) (expr_list:REG_DEAD (reg/v:SI 20 %r20 [orig:123 <anonymous> ] [123]) (expr_list:REG_BR_PROB (const_int 10000 [0x2710]) (nil)))) ;; Registers live at end: 2 [%r2] 28 [%r28] 30 [%r30] ;; Successors: 14 [100.0%] (fallthru) ;; Basic block 14, loop depth 0, count 0 ;; Predecessors: 13 [100.0%] (fallthru) 1 [100.0%] ;; Registers live at start: 2 [%r2] 28 [%r28] 30 [%r30] (code_label 186 180 241 14 19 "" [2 uses]) [snip] Yes, that is an awful weird jump_insn, but the PA really can do that in one machine instruction. ("movb,>= %r20,%r28,.L25" is what it would wind up looking like.) Anyway, there is nothing that I see wrong with this. After reordering completes, verify_flow_info gets called, and objects: pr10024.c:10: error: Wrong amount of branch edges after conditional jump 8 The "8" refers to basic block 8. It transpires that basic block 8 used to be basic block 13: ;; Basic block 8, loop depth 0, count 0 ;; Predecessors: 17 [100.0%] (can_fallthru) 7 [100.0%] (fallthru,can_fallthru) ;; Registers live at start: 2 [%r2] 20 [%r20] 30 [%r30] (code_label 159 262 236 8 13 "" [1 uses]) (note 236 159 162 8 [bb 8] NOTE_INSN_BASIC_BLOCK) (note 162 236 180 8 NOTE_INSN_DELETED) (jump_insn 180 162 302 8 0x4001b65c (parallel [ (set (pc) (if_then_else (ge (reg/v:SI 20 %r20 [orig:123 <anonymous> ] [123]) (const_int 0 [0x0])) (label_ref 186) (pc))) (set (reg/v:SI 28 %r28 [orig:104 <anonymous> ] [104]) (reg/v:SI 20 %r20 [orig:123 <anonymous> ] [123])) ]) 232 {*pa.md:7408} (nil) (expr_list:REG_DEAD (reg/v:SI 20 %r20 [orig:123 <anonymous> ] [123]) (expr_list:REG_BR_PROB (const_int 10000 [0x2710]) (nil)))) ;; Registers live at end: 2 [%r2] 28 [%r28] 30 [%r30] ;; Successors: 9 [100.0%] (fallthru,can_fallthru) You will note that it still says (label_ref 186) and there is only one outgoing edge from this block. The successor block is now ;; Basic block 9, loop depth 0, count 0 ;; Predecessors: 15 [100.0%] (can_fallthru) 14 [100.0%] 12 [100.0%] (can_fallthru) 11 [100.0%] 8 [100.0%] (fallthru,can_fallthru) ;; Registers live at start: 2 [%r2] 28 [%r28] 30 [%r30] (code_label 302 180 284 9 27 "" [2 uses]) Whoops. Could you please look into this? It is easy to reproduce using an x86 -> hppa cross compiler; I have been using --host=i686-linux --target=hppa-linux. zw p.s. 3.3 has a related problem - see my earlier message - and when my patch is applied, you get damn silly code out: extrs %r28,15,16,%r19 .L25: extru %r28,16+1-1,1,%r28 .L26: bv %r0(%r2) addl %r19,%r28,%r28 # ... .L13: movb,>= %r20,%r28,.L25 extrs %r28,15,16,%r19 b .L26 extru %r28,16+1-1,1,%r28 This should've been collapsed to .L1: extrs %r28,15,16,%r19 extru %r28,16+1-1,1,%r28 bv %r0(%r2) addl %r19,%r28,%r28 # ... .L2: b .L1 movb %r20,%r28 and I bet this would have happened if not for the weird move-and-branch instruction. It's possible that the sanest thing to do is generate these only in MACHINE_DEPENDENT_REORG or delay-slot filling.
next reply other threads:[~2003-03-26 20:36 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-03-26 20:46 Zack Weinberg [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-04-06 19:46 Zack Weinberg 2003-04-06 12:06 Jan Hubicka 2003-04-06 0:26 Zack Weinberg 2003-04-05 23:16 Richard Henderson 2003-03-27 1:06 Jan Hubicka 2003-03-26 18:45 Zack Weinberg 2003-03-26 18:36 Zack Weinberg 2003-03-14 15:14 optimization/10024: " ebotcazou
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=20030326203600.15742.qmail@sources.redhat.com \ --to=zack@codesourcery.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@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: linkBe 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).