[PATCH] Support Cell SPU floating point

Geert Bosch bosch@adacore.com
Tue Dec 18 06:16:00 GMT 2007


On Dec 17, 2007, at 18:07, Trevor_Smigiel@playstation.sony.com wrote:
> Ping?
>
> * Trevor Smigiel <Trevor_Smigiel@playstation.sony.com> [2007-10-25  
> 12:15]:
>> Are there any further comments on this patch?
>>
>> If not, is it ok for mainline?
While I can't approve your patch, I have a few comments/questions in the
hope that this will solicit more authoritative review.
>>
>>> ! @defmac DENORM_OPERANDS_ARE_ZERO (@var{mode})
>>> ! If defined, this macro should be true for @var{mode} if a  
>>> denormalized
>>> ! number should be converted to zero before constant folding an  
>>> operation.
>>> !
>>> ! The default definition of this macro is false for all modes.
>>> ! @end defmac
>>> !
>>> ! @defmac DENORM_RESULTS_ARE_ZERO (@var{mode})
>>> ! If defined, this macro should be true for @var{mode} if the  
>>> results of
>>> ! a constant folded operation is a denormalized number which  
>>> should be
>>> ! converted to zero.
>>> !
>>> ! The default definition of this macro is false for all modes.
>>> ! @end defmac
[...]
>>>
>>> + /* True when the given mode fully supports denormalized numbers.  
>>> */
>>> + #define HONOR_NONIEEE_DENORMS(MODE) \
>>> +   (!DENORM_OPERANDS_ARE_ZERO (MODE) && !DENORM_RESULTS_ARE_ZERO  
>>> (MODE))
>>> +
So, HONOR_NONIEEE_DENORMS(MODE) is true by default?
This predicate seems dubious, because the definition would apply
to modes that fully honor IEEE denorm semantics.

>>> Index: gcc/builtins.c
>>> ===================================================================
>>> *** gcc/builtins.c	(revision 128153)
>>> --- gcc/builtins.c	(working copy)
>>> *************** fold_builtin_abs (tree arg, tree type)
>>> *** 9291,9297 ****
>>>  static tree
>>>  fold_builtin_fmin_fmax (tree arg0, tree arg1, tree type, bool max)
>>>  {
>>> !   if (validate_arg (arg0, REAL_TYPE) && validate_arg (arg1,  
>>> REAL_TYPE))
>>>      {
>>>        /* Calculate the result when the argument is a constant.  */
>>>        tree res = do_mpfr_arg2 (arg0, arg1, type, (max ?  
>>> mpfr_max : mpfr_min));
>>> --- 9291,9298 ----
>>>  static tree
>>>  fold_builtin_fmin_fmax (tree arg0, tree arg1, tree type, bool max)
>>>  {
>>> !   if (validate_arg (arg0, REAL_TYPE) && validate_arg (arg1,  
>>> REAL_TYPE)
>>> !       && !HONOR_NONIEEE_DENORMS (TYPE_MODE (type)))
>>>      {
>>>        /* Calculate the result when the argument is a constant.  */
>>>        tree res = do_mpfr_arg2 (arg0, arg1, type, (max ?  
>>> mpfr_max : mpfr_min));
It seems that you disable this optimization for modes with regular  
IEEE denorms.
Am I missing something obvious?

Apart from the HONOR_NONIEEE_DENORMS related issues, the  
real_arithmetic_fold and
real_compare_fold seem to make sense: by default we keep the current  
semantics,
which is either dynamic rounding (changeable at run-time) or round-to- 
even,
but separate routines exist taking a mode. We can expand the non-IEEE  
modes we
recognize over time and/or grow the number of functions that support  
such specified
modes.

The name seems strange though, because the difference between  
real_arithmetic_fold
and real_arithmetic is not that one folds and the other doesn't, but  
that one uses
a specific mode and the other doesn't. So a name like  
real_arithmetic_mode or
real_arithmetic_in_mode would seem more descriptive.

   -Geert



More information about the Gcc-patches mailing list