Re: Question about compare rtl

[Ian Lance Taylor <iant at google dot com>]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

>>> So the question is more about the RTL difference there would be between
>>> (set (pc) (if_then_else (lt (sub r0 r1) (const_int 0)) (label_ref) (pc)))
>>> and
>>> (set (pc) (if_then_else (lt r0 r1) (label_ref) (pc)))
>>> and the ability / correctness to merge both insn (if different) with a
>>> (sub r0 r1) (in combine or cse pass).
>> 
>> The first one (lt (sub r0 r1) (const_int 0)) can be combined with a sub
>> insn, if the result of the sub insn is not used. 
>
> It cannot combine the sub with a cbranch if the result is used (maybe
> because of DFG consideration?). but in my case, the cbranch is expanded
> into a compare insn and a branch<condition> insn which enables combining
> the sub and the compare.

To be clear, combine does not generate the input to a define_expand.  It
only generates patterns that are matched by a define_insn.  So what you
are describing would only work if you implement a conditional branch via
a define_insn, and then use a define_split to split it up into the
actual instructions.

> It doesn't seems to be the best practice according to
> http://gcc.gnu.org/wiki/general_backend_cleanup (I'm not sure why), but
> it enables better optimizations and/or many less peephole to write...

Are you talking about CC0?  Don't use CC0 in a new port.  It requires a
lot of special case code in the backend.  That code is rarely tested
because very few ports still use CC0.


>> The second one can not.
>
> I did not test, but perhaps it can in my case?

How?

Ian