This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: approaches to carry-flag modelling in RTL


On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson <rth@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]