This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Handle fabs(x) UNGE 0.0
Roger Sayle <roger@www.eyesopen.com> writes:
...
> 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.
...
> 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.
I think it would be better if those backends were changed to do this.
BImode is even easier for the RTL optimizers.
> 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
The history of this is that CCmode was invented to represent the
powerpc backend's condition code registers (that's why CCmode is 4
bits). Later it was abused for things that weren't really very
similar, causing problems like the ones you're seeing, and then BImode
was invented to properly represent the other things.
--
- Geoffrey Keating <geoffk@geoffk.org>