Re: [RFC] new post-reload compare elimination pass

[Richard Henderson <rth at redhat dot com>]

On 11/29/2010 09:50 PM, Jeff Law wrote:
> At first glance this reminded me a lot of the old comparison
> elimination code in final, as it should since the code we want to
> generate is the same ...

Yes, that's the idea: giving us a proper rtl replacement for the
cc0 compare elimination from final.

> With that in mind, I looked over the old code in final.c to see if
> there were any high level gotchas -- the only ones that stuck out
> where checks to ensure the comparison didn't have a volatile operand
> or an operand with an auto-increment addressing mode. I don't see
> similar checks in your new pass.

I validate that the comparison is exactly (compare (reg) (const_int)).
I don't allow memory operands at all.

> I don't think it's necessary right now, but handling conditional
> moves, conditional traps & setcc insns might be useful one day as
> well.

I'm not specifically checking for jumps.  In theory it does handle
conditional moves and setcc, but mn10300 doesn't have any of those
to test with.

I'm planning to convert the RX port as well, which does have setcc
and movcc patterns to deal with, and was also switched from cc0 to
flags register within the 4.6 release cycle.

> Overall, the pass looks pretty simple. I presume you verified it
> actually eliminated some comparisons on the mn103 port? Did NickC
> give you a testcase or two to work with?

No, I've just been examining make all-target output and comparing
results between gcc 4.5 (pre-cc0 removal) and current.  I should
think a proper test is that we don't regress the size of libc.a.


r~