This is the mail archive of the
`gcc-patches@gcc.gnu.org`
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] |

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

**References**:**Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax***From:*Andrew Pinski

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |