[PATCH] Support Cell SPU floating point

[trevor_smigiel@playstation.sony.com]

Ian,

The changes I am proposing would not lead to any silent changes.  They
are all controlled by some macro or flag and would only be enabled for
Cell SPU.

The users I care about, PS3 programmers, do care that constant folding
match the hardware precisely.  There are definitely cases where they
intentionally tune their code to rely on exactly what the hardware
provides.  If some build decides to inline or optimize differently,
leading to constant folding that didn't happen before and thus different
results, it could very well lead to incorrect behavior in a game.

I'll make the FLO_mode changes, thanks for the explanation.

Trevor

* Ian Lance Taylor <iant@google.com> [2007-09-05 07:15]:
> "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