This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: alpha failure on 920810-1
- To: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Subject: Re: alpha failure on 920810-1
- From: Richard Henderson <rth at cygnus dot com>
- Date: Wed, 29 Apr 1998 22:57:53 -0700
- Cc: Jim Wilson <wilson at cygnus dot com>, rth at cygnus dot com, egcs at cygnus dot com
- References: <199804290430.VAA25220@rtl.cygnus.com> <199804292113.WAA32444@phal.cygnus.co.uk>
- Reply-To: Richard Henderson <rth at cygnus dot com>
On Wed, Apr 29, 1998 at 10:13:05PM +0100, Joern Rennecke wrote:
> If it tests only if all bits are zero, I think we should express this
> as a DImode equality test to zero:
>
> (set (reg:DF 1)
> (eq:DF (reg:DF 2) (reg:DF 3)))
> (set (reg:DF 4)
> (if_then_else:DF (eq (subreg:DI (reg:DF 1) 0)
> (const_int 0))
> (reg:DF 5)
> (reg:DF 4)))
Unfortunately that is not the whole truth. I read the fine print
last night and found that it handles -0.0 specially, so it is not
really a DImode compare. Which is unfortunate, since I'd like to
be able to do real DImode comparisons with them...
In conversation with Jim today, we decided that
(set (reg:DF 1) (eq:DF (reg:DF 2) (reg:DF 3)))
(set (reg:DF 4)
(if_then_else:DF (eq:CC (reg:DF 1) (const_int 0))
(reg:DF 5) (reg:DF 4)))
is a reasonable compromise. It turns out that combine already knows
that it can't do anything with CCmode compares, and with my previous
patch modified just a tad, that takes care of loop, jump, and cse.
I've bootstrapped succesfully with these changes, and am currently
running Spec95. Patches will follow once no regressions are shown.
r~