New development branch: ia64-fp-model-branch

[Zack Weinberg]

Geert Bosch <bosch@gnat.com> writes:

> For both systems it makes sense in my opinion to have a notion of
> __fpreg. It is essential that spilling/filling does not introduce
> *any* form of rounding or other observable behavior.  That
> optimization levels affect results of numerical algorithms is one of
> the greatest failures of GCC on x86.

I need to make a couple of things clear.

First, I am not doing this project for fun, or for the good of all,
or anything like that.  I'm doing it because one of CodeSourcery's
clients is paying for it.  And that client is not paying us to do
anything whatsoever to the i386 back end.  As such, while it will
certainly be nice if we get a fix for the 387's rounding problems
out of this, I consider it to be an optional extra.

Second, my understanding of the 387 instruction set and register file
is sketchy in the extreme, such that I do not feel qualified to say
what should be done to the i386 back end in order to eliminate the
rounding problems.  Further, I'm not terribly interested in solving
the problems with the 387, because it looks like both Intel and AMD
want the world to migrate to -mfpmath=sse.

> Also, it is not acceptable to go into the "very unlikely to mess
> up your answers" mode. When arbitrary extra rounding becomes very
> rare, it just makes it harder to find the cause when an otherwise
> perfectly fine program produces a wrong result. It will happen.

While I agree on a philosophical level, the passive rounding feature
of __fpreg is a case of "the customer is always right".  The design
spec I posted on the wiki is a paraphrasis of information provided to
me by the aforementioned CodeSourcery client; further, it doesn't
appear there, but they told me that passive rounding was considered
an essential property of the data type.

The use cases for __fpreg are all situations where you would have
written the damn thing in assembly language if it weren't so hard
to schedule code by hand for an ia64 processor.  It is not intended
for general use, and it is considered acceptable to have to stare at
the assembly dump and convince yourself that yes, that is what you
meant.

> It's also a good idea to have extra flags for arithmetic operations
> that specify properties such as expected rounding mode (specific, or
> "default") and behavior on overflow. This would be useful for both
> integer and float operations.

Would be nice, but is decidedly out of scope of what I am being paid
to implement.

zw