Re: Handle fabs(x) UNGE 0.0

[Roger Sayle <roger at www dot eyesopen dot com>]

Hi Geoff,
> > To extend your example consider:
> >
> >   (set (reg:CC 123) (unge:CC (abs:DF ...) (const_double 0.0))
> >   ... (eq (reg:CC 123) (const_int 0))
>
> Um, the compiler shouldn't do that.

It's a shock to discover the number of different ways GCC's backends
represent condition codes :>

> It does
>
> (set (reg:CC 123) (compare:DF (abs:DF ...) (const_double 0.0)))
> ... (eq (reg:CC 123) (const_int 0))

Not quite.  There are (atleast) two different flavours of CCmode in use.
In the first, the CCmode register is operation-less, this uses "compare"
to set CCmode, and then the use of the CCmode register provides the
operator.  In the second, the CCmode register holds the Boolean result
of a relational operator, as the SET_SRC.

Note that in your code above, you've changed the original semantics
to "abs(x) == 0.0" as you use "eq" on the CCmode register.

In the second form, if the comparison may be evaluated at compile
time, simplify_rtx will produce "(set (reg:CC 123) [true or false])".
This form is actually far easier for the RTL optimizers to work with,
as constant comparisons are much easier to simplify.  Yes, in theory,
the backends that currently use this form could potentially use BImode
instead.


The powerpc backend, for example, uses the first form which is why my
patch for PR 10011 had to treat "(compare:CC (const_int 0) (const_int 0))"
as a constant in GCSE.
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01527.html

Roger
--