Re: fold_truthop patch causes sparcv9 testsuite regressions

[Roger Sayle <roger at eyesopen dot com>]

Hi David,
> Thanks for tracking this down Rainer.  I don't think Roger's patch can
> be blamed for the failure though.
>
> Rather, I think for some reason the backend (when sparcv9/-m64) is
> illegally generating libcalls for remainder operations.  It should
> never do this, it should always use the hardware instructions.
>
> It could be due to bad instruction matching tests in sparc.md, which
> results in the compiler thinking that certain kinds of remainder
> operations cannot be done in hardware need a libcall.  I haven't
> looked deeply into this, but since there is a bugzilla entry open it
> can get tracked.

I believe there are two bugs here.  The first is that the sparc
backend shouldn't be generating libcalls, as you've mentioned.
The second is that the set of libcalls used by a function is being
determined too early.  The libcall in 20000511-1.c is eliminated
by GCSE, yet a ".global .rem" line is still emitted.  One workaround
might be to determine the set of libcalls much later in GCC.  My
guess is that the instruction matching tests in the sparc end
realize that it'll be eliminated, so don't both matching the
nonsense hardware instruction.

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.

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