------- 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
