------- Comment #5 from steven at gcc dot gnu dot org 2009-07-24 08:25 ------- The fact that the move sets the condition code is not modelled in the insn.
>From .expand dump: (insn 6 5 7 3 t.c:5 (set (reg/v:SI 133 [ v ]) (reg:SI 0 r0)) -1 (nil)) >From -dAP output: @(insn 6 5 7 t.c:5 (set (reg/v:SI 1 r1 [orig:133 v ] [133]) @ (reg:SI 0 r0)) 167 {*thumb1_movsi_insn} (nil)) @ 0x0004 mov r1, r0 @ 6 *thumb1_movsi_insn/1 [length = 2] So the compiler never even has a chance. You could model a new pattern and let combine figure out that the move&compare can be one insn. Or you can indeed do a peephole. The problem with peepholes is that you may miss opportunities, but adding new patterns also has its downsides... -- steven at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|0000-00-00 00:00:00 |2009-07-24 08:25:30 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835