Aurelien Buhrig <aurelien.buhrig.gcc@xxxxxxxxx> 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
