On Sat, 29 Oct 2011, Peter Bigot wrote: > On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson <r...@redhat.com> wrote: > Based on what I've encountered so far, between having to duplicate many > insns (one with CC_REG, one without), adding splits to convert between them, > and making a hash of the templates for the peepholes that enable efficient > access to volatile RMW peripheral memory, it looks like using CC_MODE is > going to create a maintenance nightmare.
I came to the somewhat the same conclusion for CRIS where all insns set condition codes except move to memory and a "add reg1,reg2" (no immediate operand) and to/from special registers: there'll one clobbering and one CC_REG-setting pattern plus a load of others (peephole2's mostly) to get an exact match. What would help is a kind of iterator that (also) affects the form of the insn, so you could match the clobbering and the cc0-setting insn in the same (iterator-using) pattern. BTW, I don't think it helps that someone decided the canonical form of a parallel that includes a CC-setter must have the CC-setting *first* (contrasting with the position of clobbers)... To answer your later question: The main win from moving *from* cc0 is easier maintenance for the *rest* of gcc: no need to special-case cc0; its implicit setting is a complicating factor when working at the RTL level. Albeit some minor optimizations are disabled when cc0 is encountered (IIRC), last I checked a trivial transformation from cc0 to explicit CC_REG loses performance; additional work (peephole2's and the equivalence of avr_reorg) is needed to get it back. brgds, H-P