This is the mail archive of the gcc-patches@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: Handle MODE_CC in gen_lowpart_common


> Date: Sat, 10 May 2003 07:15:40 -0600 (MDT)
> From: Roger Sayle <roger@www.eyesopen.com>
...

> As you note, BImode is a relative new comer on the scene, and wasn't
> available as recently as GCC v2.95.  However, the dual modes of
> operation of condition code registers predates even the rs6000 backend,
> dating back to cc0 and the origins of GCC.
> >From the documentation:
> 
> >> There are two ways to use it:
> >> o  To stand for a complete set of condition code flags.  This is
> >>    best on most machines, where each comparison sets the entire
> >>    series of flags.
> >>    ...
> >> o  To stand for a single flag that is the result of a single
> >>    condition.
> >>    ...

This documentation is about CC0, not MODE_CC registers.

Your patch does not follow these rules anyway; the two bits you didn't
quote read:

> With this technique, @code{(cc0)} may be validly used in only two
> contexts: as the destination of an assignment (in test and compare
> instructions) and in comparison operators comparing against zero
> (@code{const_int} with value zero; that is to say,
> @code{const0_rtx}).
...
> With this technique, @code{(cc0)} may be validly used in only two
> contexts: as the destination of an assignment (in test and compare
> instructions) where the source is a comparison operator, and as the
> first operand of @code{if_then_else} (in a conditional branch).

In none of these contexts is (cc0) ever compared against, or set to,
anything other than (const_int 0).

> GCC currently supports both these uses of MODE_CC registers in back-ends
> to support the current push to upgrade cc0 backends to use MODE_CC
> instead.  In an ideal world, these "binary" cc0 and "binary" MODE_CC
> backends would indeed upgrade still further to BImode.  However, the
> current rate of rewriting of cc0 targets would indicate that this may
> be several years away.
> 
> In the meantime, GCC supports about five ways of representing conditional
> branches in RTL.  Enabling the RTL optimizers to work as efficiently as
> possible on all of them, allows back-ends to choose the representation
> that best matches their hardware's behaviour.

... and leads to confusion, semantic problems, and incorrect code
generation.

> > I think it would be better if those backends were changed to do this.
> > BImode is even easier for the RTL optimizers.
> 
> I don't believe you intended to reject/stall a valid two-line optimization
> patch purely because it doesn't apply to a particular backend's prefered
> target representation.  I agree that BImode may be a better long term
> solution.  However, I think its perhaps unfair to deny optimizations to
> some targets [including primary evaluation platforms] purely to motivate
> change, especially in voluntary projects.  For example, I also submit
> optimizations for the PowerPC even though that doesn't use BImode either.

I'm concerned that this patch assumes semantics of MODE_CC which may
not be valid for all ports and which are known to be invalid (but
perhaps harmlessly so) for at least one port.

I agree that backends should choose the representation that best
matches their hardware's behaviour; I think this patch would be
at best useless and at worst harmful if this was done.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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