From mboxrd@z Thu Jan  1 00:00:00 1970
From: Richard Henderson <rth@cygnus.com>
To: Jim Wilson <wilson@cygnus.com>
Cc: Richard Henderson <rth@cygnus.com>, egcs@cygnus.com
Subject: Re: alpha failure on 920810-1
Date: Wed, 29 Apr 1998 02:20:00 -0000
Message-id: <19980428230405.38649@dot.cygnus.com>
References: <19980427014147.34497@dot.cygnus.com> <199804290430.VAA25220@rtl.cygnus.com>
X-SW-Source: 1998-04/msg01141.html

On Tue, Apr 28, 1998 at 09:30:43PM -0700, Jim Wilson wrote:
> I suspect that there are no currently supported machines for which your
> get_condition change is wrong, but there may be future architectures for
> which is it wrong.

Actually, part of the comment was _defining_ FPmode+VOIDmode to act a 
that way.  That future architecture might use FPmode+FPmode for that.

Sigh.  It wasn't such a good idea, I guess.

> Adding a strategic unspec operation could fix the problem, at the expense
> of uglifying the alpha.md file a bit, and perhaps losing some optimizations.
> It is likely a simpler solution though.

Hum.  I suppose 

	(set (reg:DF 1)
	  (eq:DF (reg:DF 2) (reg:DF 3)))
	(set (reg:DF 4)
	  (if_then_else:DF (eq (unspec [(reg:DF 1)] 9)
			       (const_double 0))
			   (reg:DF 5)
			   (reg:DF 4)))

would work.  It would still allow the sense of the comparisons to be
switched while disallowing their combination.  It doesn't strike me
as particularly nice, though.

As for combine, I think it needs fixing for other reasons -- Sparc v9
is failing the same test because of the same type of problem, that is,
the entire function being optimized away.  But it is doing it in a way
different from what was happening on Alpha -- I havn't examined it in
detail yet.

So you think changing get_condition and possibly combine is the wrong
approach, eh?  Well, I guess I'll figure something out...


r~