[PATCH] Support Cell SPU floating point

Ian Lance Taylor iant@google.com
Wed Sep 5 14:14:00 GMT 2007


"Richard Guenther" <richard.guenther@gmail.com> writes:

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

Are we sure that is correct?  Why have we never needed this for any
other processor?  Most processors face these issues when folding
single-precision floating-point constants.  We seem to be happy to
have gcc fold all floating-point constant operations in a higher
precision.  Why do we want to change this?

If we do change this it's going to change for everybody, which would
seem to be an unexpected silent change.  Are we confident that it is
the right choice?  For people writing casual floating point code, it
seems to me that it will be the wrong choice, just as most people
prefer the compiler to generate fused multiply-add instructions.

Alternatively, shouldn't this behaviour be enabled by an option
similar to -ffloat-store: give me precise floating point semantics
even when folding constants?


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

It seems that it should be possible for fp-bit.c to #include
"machmode.h".  At least, I don't see anything obvious that would
fail.  If that works, then it would be easy for fp-bit.h to define
FLO_mode in parallel to FLO_type.

Ian



More information about the Gcc-patches mailing list