[Bug rtl-optimization/87902] New: [9 Regression] Shrink-wrapping multiple conditions
iii at linux dot ibm.com
gcc-bugzilla@gcc.gnu.org
Tue Nov 6 12:46:00 GMT 2018
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.
More information about the Gcc-bugs
mailing list