On 02/09/2011 08:55 AM, Anitha Boyapati wrote: > 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)
You do not have to support reverse-conditional branches in your port, and frankly I encourage you not to do so. These patterns are, or ought to be, long obsolete. > 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>" See reverse_condition_maybe_unordered -- the true inverse of GT is UNLE. That is, UNORDERED || LE. Support as many of the UNORDERED comparisons as possible and you'll obviate the need for the reverse-conditional patterns, and also prevent the generation of conditions that cannot be implemented on your target. >From what I can determine re avr32 fcmp.s, you cannot support any of the compound unordered comparisons directly. You can only handle ORDERED and UNORDERED via the overflow (V) bit; there are no branches that combine V with any other flag in a way that's useful for floats. r~
