>> 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. 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... > The second one can not. I did not test, but perhaps it can in my case? >> And the main question is: can the N==1 test be useful for the backend? >> For instance, in C, I think an overflow has undefined behavior, so >> testing for an overflowed result seems meaningless. > > Signed overflow is undefined, but unsigned overflow wraps. So it is > possible to write valid code that could use an overflow flag using > unsigned types. But it's uncommon. Yes indeed, the overflow can be tested, but with an unsigned comparison (which are evaluated according to the carry flag). When combining a (sub r0 r1) with a cbranch (lt (sub r0 r1) const_int 0), testing for N == 1 or N xor V == 1 may lead to different behavior. If signed overflow are generally undefined, such a difference only in the undefined case when a signed overflow occurs. So it definitely means that the N==1 test is useless... > Anything > involving condition flags is harder to generate code for, although I > understand that it permits additional pipelining in the processor. If > the processor has to have condition flags then I suspect that the best > results will come from instructions that store the results of the > condition in a general register, and conditional branches that can test > any general register against zero. Yes, it would be nice, especially for the cstore pattern. Thank you very much for your help! Aurélien
