On 9 February 2011 20:34, Ian Lance Taylor <i...@google.com> wrote: >> I would like to know what prompts gcc to decide if "le" can be used in >> the expand pass rather than "gt" operator. Or more precisely why it >> differs incase of float. > > The choice of LE when using int is just a happenstance of the way that > gcc generates code. When gcc comes to RTL generation it happens to be > looking at an if statement that falls through on true and branches on > else. So it flips the condition to branch on true (in > do_compare_rtx_and_jump). The use of volatile doesn't affect this: it > will still only load the variables precisely as described in the > program. > > The condition can not be flipped for float because that would be an > invalid transformation if one of the values is NaN. >
ok. I get it. I would like to understand some more of reverse-conditional branches in case of float. For the target I am working on (AVR32), there is a floating point unit which follows IEEE 754. The port is relatively stable. We are now incrementally building support for these FPU instructions (like fadd, fmul, fcmp). Now for the same test case with float data type, after expand pass, in one of the passes (outof_cfglayout) the direct-conditional branches are turned to reverse-conditional branches. Direct-conditional branch > (jump_insn 9 8 34 3 gt.c:4 (set (pc) > (if_then_else (gt:CC (cc0) > (const_int 0 [0x0])) > (label_ref 12) > (pc))) -1 (nil)) Reverse-conditional Branch > (jump_insn 9 8 34 3 gt.c:4 (set (pc) > (if_then_else (gt:CC (cc0) > (const_int 0 [0x0])) > (pc))) -1 (nil)) > (label_ref 14) (Sorry that I don't have access to the installation right now, so I just manually modified the reverse-conditional branch. The idea is to illustrate that label_ref and pc are interchanged). The latter pattern is supposed to emit assembly which tests for the reverse-condition. For instance if the former pattern emits assembly instruction like "brgt <label>" then the latter pattern is supposed to emit instruction like "brle <label>" I am a little confused here. I think this kind of condition reversal should not happen for floating point comparisons (IEEE 754). Am I on the right track still? If yes, how to prevent this kind of jump optimization? I see some REVERSIBLE_CC_MODE which is not defined in our case. Also not defined is REVERSE_CONDITION... Moreover I see that this kind of interdependence of patterns in jumps has been removed when the branch "cond-optab" got merged. So this condition-reversal branch may not be seen in higher versions of gcc ? (like 4.5.1) I am not sure if I am overloading this conversation with too many of questions...I am trying to present the problem(s) clearly. Thanks Ian for the hint on do_compare_rtx_and jump ()!! That was exactly what I looked for. Anitha
