Re: [PATCH] Support Cell SPU floating point

[trevor_smigiel at playstation dot sony dot com]

* Richard Guenther <richard.guenther@gmail.com> [2007-08-29 14:35]:
> On 8/29/07, trevor_smigiel@playstation.sony.com
> <trevor_smigiel@playstation.sony.com> wrote:
> > * Richard Guenther <richard.guenther@gmail.com> [2007-08-29 02:00]:
> > > On 8/29/07, trevor_smigiel@playstation.sony.com
> > > <trevor_smigiel@playstation.sony.com> wrote:
> > > > This patch does three things:
> > > >
> > > > 1) Add Cell SPU extended single precision format to real.c
> > > > 2) Define macros for constant folding of denormalized numbers
> > > > 3) Define macros to prevent certain optimizations on denorms
> > > >
> > > > The latter 2 parts are necessary to get proper constant folding and
> > > > optimization on SPU which does not fully support IEEE floats.  A comment
> > > > in real.c describes the differences:
> > > >
> > > > /*  SPU Single Precision (Extended-Range Mode) format is the same as IEEE
> > > >     single precision with the following differences:
> > > ...
> > > >       - the only supported rounding mode is trunction (towards zero)
> > >
> > > Uh.  You know you need to enable -frounding-math always then?  Or do SPU users
> > > not care if the compiler optimizes as if the rounding mode would be round to
> > > nearest/even?
> >
> > Yes, users care.  The goal is to make constant folding model exactly the
> > behavior of the hardware.  This patch addresses the relevant issues for
> > SPU.  I won't claim this patch brings us %100 there, but it is a lot
> > closer
> >
> > To address some of the rounding issues the patch adds a
> > round_towards_zero field to the real_format structure which is then used
> > in round_for_format.  In the folding cases that I care about
> > round_for_format is getting called, and I get the results I expect.
> > I'll look more closely at the other optimizations effected by
> > -frounding-mode to make sure the appropriate things is happening.
> > Enabling -frounding-mode will certainly prevent folding effected by
> > rounding, but I don't want that.  I want the folding to be done
> > according to the format.
> 
> Well, most transformations that change the sign of one operand give
> different results once you divert from round to nearest.  Look at those
> guarded by HONOR_SIGN_DEPENDED_ROUNDING.  Unfortunately
> this predicate is built to support FPUs that only have round-to-nearest.
> There's no predicate (and thus also no special foldings) if the FPU
> only implements round to zero (that is some transformations are
> disabled because round to -infinity or +infinity would make them
> invalid).  You might want to add such, but atm I cannot think of
> a good set without adding all of HONOR_ROUND_xxx for all
> IEEE rounding modes.

I've looked more closely at what GCC does with these and it behaves
exactly the way I desire.  I only need support for round-to-zero, and
there is already a macro, ROUND_TOWARDS_ZERO, that describes that, and
the patch I proposed extended it to be mode specific.

The one thing ROUND_TOWARDS_ZERO did not seem to do was effect the
results of the code in real.c.  Though the documentation seems to
suggest that it does.  The rounds_toward_zero field in the patch 
tries to fix that.

The usage of HONOR_SIGN_DEPENDENT_ROUNDING is that a transformation will
not be performed when that macro is true.  It is only true when using
-frounding-math and the default rounding is round-to-nearest.  When the
default rounding is set to round-to-zero (by defining ROUND_TOWARDS_ZERO)
it will always be false and so the transformations will always happen,
regardless of -frounding-math.

In fact, there are a few places where flag_rounding_math is used and I
wonder if they should be changed to HONOR_SIGN_DEPENDENT_ROUNDING.  For
example, in const-fold.c, flag_rounding_math is used to prevent a fold
that was rounded, but for SPU and with the patch I proposed, it is
always valid to do that fold, because it is impossible to change the
rounding mode at run-time, and the patch now causes the folded result to
be correctly rounded according to the format.

So, without any modifications to the patch I proposed, GCC seems to be
doing the right thing.  The only thing I might want to change is the
documentation for -frounding-math which specifically mentions
round-to-nearest, but now there is better support for round-to-zero.

Trevor