On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson <r...@redhat.com> wrote: > On 10/28/2011 06:49 AM, Peter Bigot wrote: >> I'm inclined to follow sparc's lead, but is one or another of the choices >> more likely to help combine/reload/etc do a better job? > > I don't know. > > In the case of RX, we don't model CC_REG until after reload, so combine really > doesn't get a shot at it. > > Be careful here. If you explicitly model the carry flag before reload, you > need > to have an ADD instruction that can avoid any flags modification. Reload > needs > to generate such instructions in some cases, and needs to be able to insert > them > between any two arbitrary insns. > > If you're like sparc (separate add, addcc insns), or i386 (separate add, lea > insns), > then you're fine. If you're like m68k or RX and have only an add that > clobbers > the flags, then you'll have to delay splitting flags-using patterns until > after > reload is complete.
Interesting. The MSP430 ISA has add and addc insns, but both affect the flags. Most instructions affect the flags. 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'd been moving on this path based on the recommendation in the "Condition Code Status" section of GCC Internals to use CC_MODE for new ports. (Though the MSP430 isn't a "new port", in 2003 the original cc0 solution using NOTICE_UPDATE_CC was converted to something obscene that ends up instead walking the insn chain calling get_attr_cc during output template generation to identify the most recent change. No idea why; the CVS comment just says "cmp fixes and improvements".) It seems cc0 should probably still be preferred for CISC-style architectures like the MSP430. I'll give that approach a try. Thanks. Peter
