optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE

[Zack Weinberg]

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.