This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax
- From: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: Roger Sayle <roger at eyesopen dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 9 Nov 2006 23:40:31 -0500 (EST)
- Subject: Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax
- References: <200611100405.kAA45fA0006883@localhost.localdomain>
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
> 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 R. Ghazi email@example.com