Re: fold_truthop patch causes sparcv9 testsuite regressions

[Roger Sayle <roger at eyesopen dot com>]

Hi David and Rainer,
> Unfortunately, I have confirmed that removing my optimization
> does fix the problem on sparc -m64.  So if Rainer still finds
> the regression unacceptable, and we don't come up with a sparc
> backend fix, I may have to revert my patch :<.
>
> I'm still investigating whether there's a missing constant
> folding optimization which is why the remainder is being
> generated in one case and not the other.

Good news.  I've managed to analyze this failure even further,
and confirmed that this is a pre-existing problem and which
form of sparc.md's hardware "mod" patterns are failing.

A reduced test case is shown below:

int foo(int x)
{
   int y = 2;

   /* This becomes (y != 0) ? 0 : (x % 0); */
   return x % (y != 0);
}

This also fails with -m64 on sparc-sun-solaris2.8, and is present
both before and after my constant folding patch.  Hence my patch is
now safe from reversion.

The core problem is that "x % 0" is translated into a libcall to
".rem" even when "-m64" is specified.  I suspect that the pattern
doesn't handle an explicit constant zero, as demonstrated by the
following example:

int bar(int x)
{
    return x % 0;
}

Any way in the "foo" example above, GCSE eventually determines that
y is never zero, and the libcall to .rem is removed, but the memory
of "global .rem" still remains in the output.


I know nothing of machine descriptions, and don't have access to a
sparc machine, but hopefully I've tracked down the problem far enough
that Dave can take it from here.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833