Re: [PATCH] Support Cell SPU floating point

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 9/5/07, trevor_smigiel@playstation.sony.com
<trevor_smigiel@playstation.sony.com> wrote:
> Richard,
>
> Thanks for the review.
>
> Can you please give me a little more advice on how to implement the
> appropriate bits in real.c.  Even though denorms are generally treated
> as zero on SPU, they are a legitimate number on the hardware.  They can
> be generated by double precision instructions, and should be encoded
> correctly when specified as literals.  Trying to model the hardwares
> behavior only in real_convert isn't sufficient.
>
> Do you think adding a mode argument to the appropriate routines in
> real.c (e.g., real_arithmetic, real_compare) is the correct approach?
> That would allow me to model the hardware correctly.  Or do you have
> another suggestion?

Well, in general I think that adding a mode argument to those functions
makes sense (and I see that would be necessary to do what you need).

> I'm ok with the name HONOR_DENORMS, but it has a slightly different
> usage than the other HONOR_* macros.  The existing macros are used to
> mean "when this macro is true it IS NOT safe to do this optimization".
> HONOR_DENORMS will mean "when this macro is true it IS safe to do this
> optimization."

I would have expected to guard optimizations that are only valid if there are
_not_ denormal values in the FP format.  But well, I don't feel too strong about
the name.

> ROUND_TO_ZERO is used in fp-bit.c and so cannot use a mode argument.
> LARGEST_EXPONENT_IS_NORMAL is also used in fp-bit.c and uses size for an
> argument, which is why I used the same approach.

But if you use mode size that you cannot for example distinguish SFmode and a
same-size fixed float mode.  A quick look into fp-bit.c shows that it
at least has
the type available and it should be possible to make the corresponding mode
available as well.  CCing Ian on this matter.

Thanks,
Richard.