Re: [PATCH] Fix 20020720-1.c on MIPS

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 14 Oct 2002, Richard Henderson wrote:
> On Sun, Oct 13, 2002 at 10:54:08PM -0600, Roger Sayle wrote:
> > 	* combine.c (simplify_set):  Treat MODE_CC registers like cc0.
>
> Will this simplify
> 	cmpteq	$f31, $f2, $f3
> 	fbne	$f3, Label
> to
> 	fbeq	$f2, Label
>
> on alpha?  We sort of abuse CCmode to prevent this at the moment.
> Just in case you're wondering, cmpteq handles NaN, but fbeq doesn't.

I guess there'd be a test for this in the testsuite and as I mentioned
with the original posting there are no new regressions in any of GCC's
testsuites using this patch on alphaev67-dec-osf5.1.   However, just to
double check I just tried the following simple test by hand:


void foo(double x, double y)
{
  if (x == y)
    bar1();
  else
    bar2();
}

which generates the following:

foo:
        ldgp $29,0($27)
        lda $30,-16($30)
        stq $26,0($30)
        cmpteq $f16,$f17,$f16
        fbeq $f16,$L2
        jsr $26,bar1
        ldgp $29,0($26)
$L1:
        ldq $26,0($30)
        lda $30,16($30)
        ret $31,($26),1
$L2:
        jsr $26,bar2
        ldgp $29,0($26)
        br $31,$L1


So it looks like this patch preserves the "cmpteq ... ; fbeq ..."
sequence on the alpha.  Not knowing this backend, I'd guess the mode
of the comparison isn't valid recognized as applicable in the fb??
patterns.  Of course, this simple test might not be sufficient to
trigger the optimization in combine.  I also tried (*x == *y) where
the parameters were "double*", which also preserved this sequence.


Is this a sufficient answer?  Are there any other tests we could try?
I'd normally argue that if there was a problem of this type it'd be
picked up by a GCC bootstrap, but I suspect neither the compiler
nor its testsuite test would help in finding a NaN comparison issue.
Perhaps SPECfp2000 on alpha?

Roger
--