https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749
--- Comment #4 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
Hi, sorry I missed this. I need to write a better filter for bugs I'm CCed on,
I'll work on that.
I'm hitting the limits of what I can guess from the Sparc machine files. I
don't understand why we get an expansion for the conditional branch that
explicitly generates new temporaries for i and j, necessitating an if..else..
structure.
Compare how we expand on Sparc:
---
(insn 12 5 13 2 (set (reg:CC 100 %icc)
(compare:CC (subreg/s/u:SI (reg/v:DI 113 [ xD.1388+-4 ]) 4)
(subreg/s/u:SI (reg/v:DI 114 [ yD.1389+-4 ]) 4)))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:12 -1
(nil))
(jump_insn 13 12 14 2 (set (pc)
(if_then_else (le (reg:CC 100 %icc)
(const_int 0 [0]))
(label_ref:DI 29)
(pc))) ../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:12 48
{*normal_branch}
(int_list:REG_BR_PROB 3900 (nil))
-> 29)
;; succ: 4 [61.0%] (FALLTHRU)
;; 5 [39.0%]
;; basic block 4, loop depth 0, count 0, freq 6100, maybe hot
;; prev block 2, next block 5, flags: (NEW, REACHABLE, RTL, MODIFIED)
;; pred: 2 [61.0%] (FALLTHRU)
(note 14 13 8 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 8 14 9 4 (set (reg/v:SI 110 [ jD.1394 ])
(subreg:SI (reg/v:DI 115 [ aD.1390+-4 ]) 4))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:15 -1
(nil))
(insn 9 8 26 4 (set (reg/v:SI 109 [ iD.1393 ])
(subreg:SI (reg/v:DI 115 [ aD.1390+-4 ]) 4))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:14 -1
(nil))
(jump_insn 26 9 27 4 (set (pc)
(label_ref 15)) -1
(nil)
-> 15)
;; succ: 6 [100.0%]
(barrier 27 26 29)
;; basic block 5, loop depth 0, count 0, freq 3900, maybe hot
;; prev block 4, next block 6, flags: (NEW, REACHABLE, RTL, MODIFIED)
;; pred: 2 [39.0%]
(code_label 29 27 28 5 3 "" [1 uses])
(note 28 29 6 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 6 28 7 5 (set (reg/v:SI 110 [ jD.1394 ])
(subreg:SI (reg/v:DI 114 [ yD.1389+-4 ]) 4)) -1
(nil))
(insn 7 6 15 5 (set (reg/v:SI 109 [ iD.1393 ])
(subreg:SI (reg/v:DI 113 [ xD.1388+-4 ]) 4)) -1
(nil))
;; succ: 6 [100.0%] (FALLTHRU)
;; basic block 6, loop depth 0, count 0, freq 10000, maybe hot
;; prev block 5, next block 1, flags: (NEW, REACHABLE, RTL)
;; pred: 5 [100.0%] (FALLTHRU)
;; 4 [100.0%]
(code_label 15 7 16 6 2 "" [1 uses])
(note 16 15 17 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 17 16 18 6 (set (reg:DI 117)
(mult:DI (subreg:DI (reg/v:SI 109 [ iD.1393 ]) 0)
(subreg:DI (reg/v:SI 110 [ jD.1394 ]) 0)))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:17 -1
(nil))
---
Where [bb 5] acts as an else block setting registers 109/110 to the "old"
values. And the AArch64 expansion of the same:
---
(insn 10 5 11 2 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 74 [ xD.2750 ])
(reg/v:SI 75 [ yD.2751 ])))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:12 -1
(nil))
(jump_insn 11 10 12 2 (set (pc)
(if_then_else (le (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 13)
(pc))) ../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:12 -1
(int_list:REG_BR_PROB 3900 (nil))
-> 13)
;; succ: 4 [61.0%] (FALLTHRU)
;; 5 [39.0%]
;; basic block 4, loop depth 0, count 0, freq 6100, maybe hot
;; prev block 2, next block 5, flags: (NEW, REACHABLE, RTL, MODIFIED)
;; pred: 2 [61.0%] (FALLTHRU)
(note 12 11 6 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 6 12 7 4 (set (reg/v:SI 75 [ yD.2751 ])
(reg/v:SI 76 [ aD.2752 ]))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:15 -1
(nil))
(insn 7 6 13 4 (set (reg/v:SI 74 [ xD.2750 ])
(reg/v:SI 76 [ aD.2752 ]))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:14 -1
(nil))
;; succ: 5 [100.0%] (FALLTHRU)
;; basic block 5, loop depth 0, count 0, freq 10000, maybe hot
;; prev block 4, next block 1, flags: (NEW, REACHABLE, RTL)
;; pred: 2 [39.0%]
;; 4 [100.0%] (FALLTHRU)
(code_label 13 7 14 5 2 "" [1 uses])
(note 14 13 15 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 15 14 16 5 (set (reg:SI 77)
(mult:SI (reg/v:SI 74 [ xD.2750 ])
(reg/v:SI 75 [ yD.2751 ])))
../../src/gcc/gcc/testsuite/gcc.dg/ifcvt-4.c:17 -1
(nil))
---
I guess it is those subregs down from DImode to SImode. Sure enough, if we swap
int for long in this testcase, we get the expected expansion and the expected
number of true changes made.
So, I'm not worried that the optimization is broken for Sparc (it does the
right thing for long), but I'm not sure I know the best way to work around this
for your target. swapping int for long would also help HPPA. HPPA chose to skip
the test entirely. That might also be right for Sparc.
What do you think?
