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: Roger Sayle <roger at eyesopen dot com>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>, <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 10 Nov 2006 11:16:46 -0700 (MST)
- Subject: Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax
On Thu, 9 Nov 2006, Andrew Pinski wrote:
> 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.
That's what I suspected. My thinking is that perhaps we should deprecate
the use of the MIN_EXPR/MAX_EXPR tree codes for floating point types, and
instead introduce __builtin_fmin, __builtin_fmin_c99 and
__builtin_fmin_ieee (each with their own optabs) that represent the
three different semantics that we care about. This simplifies the
constant folding as testing for different BUILT_IN_FMIN* allow us to
handle/specify which -ffast-math flags are relevant with each transform.
Then backends like the powerpc which provide fmin/fmax instructions can
identify which of these semantics they implement, via the pattern name.
The expand_fmin/fmax RTL expanders can then fall back with -ffast-math,
or implement the additional machinery required for c99/java behaviour when
that is required. Hence in java "a < b ? a : b" can be recognized as
__builtin_fmin/__builtin_fmax, but the native lang.Math.min and
lang.Math.max map internally to __builtin_fmin_ieee etc...
Admittedly, it's a bit ugly, but it looks like the middle-end needs
to keep the different possible semantics separate, even though
optimizations such as min(min(1.0,x),2.0) -> min(x,1.0) apply to
all of them. Alas min(x,y) -> min(y,x), and efficient hardware
support often only apply to a subset.
We can even implement fmin_c99(x,NaN) -> x in builtins.c.
Hmm, we may have to do the same with RTX codes :-( Given the effort
I can see why we've taken the easy way of leaving our internal semantics
poorly defined (and only suitable for use with -ffast-math).