http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46088
--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-11
11:27:27 UTC ---
> The insn that was matched looks like:
>
> (gdb) up
> #1 0x0000000000b9da94 in recog_7 (x0=0x7ffff1f329d8, insn=0x7ffff1f296c0,
> pnum_clobbers=0x7fffffffdc9c)
> at ../../gcc-svn/trunk/gcc/config/i386/i386.md:10089
> 10089 && ix86_binary_operator_ok (<CODE>, <MODE>mode, operands)"
> (gdb) p debug_rtx (insn)
> (insn 7 6 8 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (lshiftrt:SI (reg/v:SI 60 [ i ])
> (const_int 3 [0x3]))
> (const_int 0 [0]))) pr46088.c:5 2 {*cmpsi_ccno_1}
> (nil))
> $1 = void
>
> So, clobber of the scratch reg is missing, but the insn is recognized as
> *lshrsi3_cconly anyway.
Yes, this is the documented behavior of the combiner so back-ends need to cope
with it. A possible approach would be to define a specialized version of
ix86_binary_operator_ok, e.g. ix86_binary_operator_ok_for_reg_dest, and uses it
in any pattern that has match_scratch as destination. The existing logic in
ix86_binary_operator_ok can avoid reading DST if it knows it's a REG.
