This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 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.

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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]