On 11 February 2011 00:20, Richard Henderson <r...@redhat.com> wrote: > On 02/09/2011 08:55 AM, Anitha Boyapati wrote: >> 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. >
Does this mean that the requirement for reverse-conditional pattern mostly arise because of unordered comparisons? It is true that our current machine description does not handle conditions 'unordered', 'unlt', 'ungt', 'unge', 'unle'... > 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. There is "brvs" which detects if the unordered/overflow bit is set and then jumps to given location. So after a floating-point comparison, when the branch is called (we are not using cbranch. The branch pattern looks exactly similar to the one described in Code Iterators section of gcc internals), we first check for unordered comparison using 'brvs' and then emit br<cond>. Since an unordered comparison is always false in IEEE 754, the emitted code will normally look like: Direct-Conditional Branches: brvs +6 //jump to fall tru br<cond> <LABEL> // cond is eq, lt, le, gt, ge ... //fall tru <LABEL>: .... But for a reverse-condition, 'brvs' should jump to label (and not to fall tru). Reverse-Conditional Branches: brvs <LABEL> // jump to LABEL for unordered br<inverse-cond> <LABEL> // ... <LABEL>: ... This is when we got hit, as to when and why a reverse-conditional branch is generated. From what I see in cond-optab branch, it looks like these are going to deprecated in 4.5 version. Going by what you said we will first try supporting unordered comparisons in code_iterators and play around it for some time to understand better :-) Thanks a lot Richard! Anitha
