Closed GoogleCodeExporter closed 9 years ago
the rtl causing the mess:
(insn 8 6 9 (set (reg:SI 134)
(plus:SI (reg/v:SI 133 [ x ])
(const_int -1 [0xffffffffffffffff]))) -1 (nil)
(nil))
(insn 9 8 10 (set (reg:DI 135)
(zero_extend:DI (reg:SI 134))) -1 (nil)
(nil))
(insn 10 9 11 (set (reg:CCUDI 136)
(compare:CCUDI (reg:DI 135)
(const_int -4 [0xfffffffffffffffc]))) -1 (nil)
(nil))
note the bit pattern of -4 in the last insn. it should really be
0x00000000fffffffc.
however, in that case, the semantics of the compare is not the same anymore: so
a
single compare won't do anymore, and the code should also test if 135 is >
0x00000000ffffffff, which makes such an optimization ... well ... a bit
suboptimal.
now, I wonder whether this will require another CC mode for unsigned SI
compares? ;)
Original comment by jmoc...@gmail.com
on 12 Feb 2009 at 1:41
the problem was that the mask (M)[1|0] notation sign-extends the negative value
from
SI to DI. unsigned compares need zero-extension, though ...
fixed in r231 by force_reg()ing negative const_ints in case of unsigned SI
compares
and explicitly zero-extending them.
might be that a similar solution would work for issue #89 ...
Original comment by jmoc...@gmail.com
on 12 Feb 2009 at 2:35
Original issue reported on code.google.com by
jmoc...@gmail.com
on 12 Feb 2009 at 1:37Attachments: