This is the mail archive of the 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

> 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).

You're now confusing where the RTX "(cc0)" can be used vs. from where
it can be assigned.  I concur with the above documentation that limits/
restricts the places where cc0 and MODE_CC registers may be read.  For
example, in a "set" insn, cc0_rtx is a valid SET_DEST, but never a
valid SET_SRC!

To reiterate, the two allowable forms of CC0 setters are:

[1]  (set (cc0) (compare:SI (foo) (bar)))
     (set (pc) (if_then_else (eq (cc0) (const_int 0)) (label) (pc))


[2]  (set (cc0) (eq:SI (foo) (bar)))
     (set (pc) (if_then_else (cc0) (label) (pc))

In the second form, but not the first, CSE, GCSE and combine may
propagate constants into the arguments of "eq", and evaluate that
subexpression at compile time, resulting in either

[2a]  (set (cc0) (const_int 0))


[2b]  (set (cc0) (const_int 1))

[Ignoring the specifics of const_true_rtx!]

If we now transpose these two sets of semantics to the prefered
replacement for cc0 condition codes, we now also have two forms
with MODE_CC, one that has uses a COMPARE rtx as a source, and
the other that uses a relational/equality operators (and integers).

The two forms are distinct and GCC's RTL optimizers never convert
one form into another.  If a backend uses one semantics, that
form is guaranteed and only optimizations that apply to that form
are applied.

For example of a patch that allows optimizations that apply to
the second form to be used with machine descriptions that use
the first form see "Simplify (cond (compare x y) 0) into (cond x y)".

> > 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 certainly won't argue that the situation is ideal.  Yes, it may be
confusing,  but the experts on the gcc-pactches that maintain the
RTL optimizers are aware of the issues.  This certainly isn't the
only part of GCC that shouldn't be modified if you don't know what
you're doing.

I'm also unaware of any cases where this has led to incorrect code
generation, but then I'm a relative new comer.  More commonly, we
have the situation where optimizations get applied on some platforms
but not others.  20020720-1.c is a classic example that required
multiple patches (eight at the last count) to ensure the optimization
was applied on different platforms, and it still fails on some!

> 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.

There are two parallel condition code universes: the compare
one and the operator one.  They exist independent and often unaware
of the existance of the other.  Some optimizations apply to one,
some to the other and some to both.  However, which semantics apply
is always clear from context.  A platform may even be able to use
one form for floating point condition codes and the other for integer
condition codes [though I wouldn't recommend it].  You might even
be able to use cc0, BImode and MODE_CC in the same port, but that
would really mess with people's minds.

> I think this patch would be at best useless and at worst harmful
> if this was done.

I'm sure you've already read David Anglin's e-mail confirming that
my patch results in significant performance improvements on PA-Risc.

Yes, this code will never trigger on PowerPC, so it is indeed at
best useless to targets that use COMPARE.  Harmful?  Well that's
just (healthy) paranoia.


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