------- Comment #29 from rakdver at gcc dot gnu dot org 2006-07-30 14:04
-------
(In reply to comment #28)
> I've been trying to figure out why we end up with the strange intialization
> for
> the
> parity loop. I see this rtl in the loop2 dump:
>
> (jump_insn 69 68 71 7 (set (pc)
> (if_then_else (ne (reg/v:SI 109 [ i ])
> (reg:SI 130))
> (label_ref 27)
> (pc))) 25 {*pa.md:1710} (nil)
> (expr_list:REG_EQUAL (if_then_else (ne (reg/v:SI 109 [ i ])
> (const_int 64 [0x40]))
> (label_ref 27)
> (pc))
> (expr_list:REG_BR_PROB (const_int 9844 [0x2674])
> (nil))))
> ;; End of basic block 7, registers live:
> (nil)
> This gets transformed to the following rtl in the loop2_init dump:
> (jump_insn 69 68 116 7 (set (pc)
> (if_then_else (ne (reg/v:SI 109 [ i ])
> (reg:SI 130))
> (label_ref:SI 116)
> (pc))) -1 (nil)
> (expr_list:REG_EQUAL (if_then_else (ne (reg/v:SI 109 [ i ])
> (const_int 64 [0x40]))
> (label_ref:SI 116)
> (pc))
> (expr_list:REG_BR_PROB (const_int 9844 [0x2674])
> (nil))))
> ;; End of basic block 7, registers live:
> (nil)
>
> ;; Start of basic block 13, registers live: (nil)
> (code_label 116 69 115 13 55 "" [1 uses])
>
> (note 115 116 71 13 [bb 13] NOTE_INSN_BASIC_BLOCK)
> ;; End of basic block 13, registers live:
> (nil)
> As a result, jump_insn 69 no longer does anything. All references
> to code_label 27 are now gone and this appears to allow stuff that
> was originally in the loop to end up as a loop initializers.
no, this seems correct to me. In cfglayout mode (that is used in the loop
optimizations), the unconditional jumps are removed and they are represented
only implicitly by edges in the cfg. BB 13 is probably a forwarder block
created by some of the loop shape canonicalization transformations, and its
single successor is the block containing label 27 (i.e., bb 13 implicitly
contains (jump_insn (set (pc) (label_ref 27)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
