https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902

            Bug ID: 87902
           Summary: [9 Regression] Shrink-wrapping multiple conditions
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: iii at linux dot ibm.com
                CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
            Target: s390x-linux-gnu

I've noticed that r265830 fails to shrink-wrap multiple early returns in
gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c, while r264877 managed to
do so just fine.

After reload we end up with the following code for those conditions:

;; basic block 2
(note 5 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 3 5 2 2 NOTE_INSN_FUNCTION_BEG)
(insn 2 3 7 2 (set (reg/v:DI 12 %r12 [orig:63 aD.2191+-4 ] [63])
        (reg:DI 2 %r2 [72]))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":14:1 1269 {*movdi_64}
     (nil))
(insn 7 2 8 2 (set (reg:CCZ 33 %cc)
        (compare:CCZ (reg:SI 12 %r12 [orig:63 aD.2191 ] [63])
            (const_int 42 [0x2a])))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":17:6 1232 {*cmpsi_cct}
     (nil))
(jump_insn 8 7 9 2 (set (pc)
        (if_then_else (eq (reg:CCZ 33 %cc)
                (const_int 0 [0]))
            (label_ref:DI 33)
            (pc))) "gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":17:6
1896 {*cjump_64}
     (int_list:REG_BR_PROB 225163668 (nil))
 -> 33)

;; basic block 3
(note 9 8 12 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 12 9 13 3 (set (reg:CCS 33 %cc)
        (compare:CCS (reg:SI 12 %r12 [orig:63 aD.2191 ] [63])
            (const_int 0 [0])))
"gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":20:3 1222
{*tstsi_cconly2}
     (nil))
(jump_insn 13 12 14 3 (set (pc)
        (if_then_else (le (reg:CCS 33 %cc)
                (const_int 0 [0]))
            (label_ref:DI 33)
            (pc))) "gcc/testsuite/gcc.target/s390/nobp-return-mem-z900.c":20:3
1896 {*cjump_64}
     (int_list:REG_BR_PROB 118111604 (nil))
 -> 33)

Note that comparisons use a copy in caller-saved %r12, and not %r2.  Then,
prepare_shrink_wrap () successfully propagates it to basic block 2. Basic block
3 is not affected - this seems to be by design, since prepare_shrink_wrap ()
only concerns itself with the first basic block.

In the past reload used to eliminate the copy and use %r2 directly in both
comparisons, but this seems to be no longer the case.

Reply via email to