Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax

["Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>]

On Thu, 9 Nov 2006, Andrew Pinski wrote:

> > This is OK for mainline.  Thanks.
> >
> > I'm not exactly sure what the official middle-end position on
> > min(0.0,-0.0) and max(0.0,-0.0) is.  I know that Java requires
> > the sign to be taken into consideration, but I'm unsure whether
> > we require this of the backend-provided min?f3/max?f3 optabs or
> > of the RTL we expand if a min/max optab isn't available.  I've
> > not checked but I've a suspicion that we generate a<b?a:b, and
> > therefore obtain an arbitrary sign.
>
> Java has already been moved away from using MIN/MAX_EXPR. See PR
> 25676.
>
> tree.def says:
> /* Minimum and maximum values.  When used with floating point, if both
>    operands are zeros, or if either operand is NaN, then it is unspecified
>    which of the two operands is returned as the result.  */
>
> Which means to me zero and negative zero are handled as zero which is why Java
> moved away from using MIN/MAX_EXPR.
> Andrew Pinski

Right.  I wish MIN/MAX_EXPR were suitable for fmin/fmax replacements.
There are a lot of optimizations in the middle-end for these EXPRs that
I'd rather not duplicate in the builtins.  Instead I'd like to be able to
lower the builtins into these codes like we do for fabs->ABS_EXPR.  But
that would require work to change all the backends to honor the new
behaviors for -0.0 and/or NaN.

Actually, I'm not sure if fmin/fmax care about -0.0, but I think they do
care about NaN vs a normal number.  Anyone got the standard handy?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu