http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #67 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-08
08:28:42 UTC ---
Perhaps it would be also good to add new peephole2 to catch:
(insn 931 415 932 33 (set (reg:CC 19 r19)
(mem/c:CC (plus:DI (reg/f:DI 1 r1)
(const_int 272 [0x110])) [5 %sfp+272 S4 A32])) where_2.f90:11
358 {*movcc_internal1}
(nil))
(insn 932 931 461 33 (set (reg:CC 74 cr6)
(reg:CC 19 r19)) where_2.f90:11 358 {*movcc_internal1}
(expr_list:REG_DEAD (reg:CC 19 r19)
(nil)))
(insn 461 932 422 33 (set (reg:SI 27 r27 [712])
(gt:SI (reg:CC 74 cr6)
(const_int 0 [0]))) where_2.f90:11 462 {*rs6000.md:13486}
(expr_list:REG_DEAD (reg:CC 74 cr6)
(nil)))
which is expanded to (if -fno-schedule-insns2, but peephole2 is run before
second scheduling):
lwz r19,272(r1)
rlwinm r19,r19,8,0xffffffff
mtcrf 2,r19
rlwinm r19,r19,24,0xffffffff
mfcr r27
rlwinm r27,r27,26,1
while only one lwz and one rlwinm are actually needed (BTW, also it would be
nice to avoid the second rlwinm in movcc_internal1 pattern if the source
integer register is dead at the insn).
I guess this can happen quite often, any time the register pressure is too high
and reload spills CC mode registers and then they are used just once for cr*
cond 0 ? 1 : 0 assignments.
