This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Question about compare rtl
>> 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