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


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