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

Reply via email to