Re: New development branch: ia64-fp-model-branch

[Zack Weinberg <zack at codesourcery dot com>]

Bradley Lucier <lucier@math.purdue.edu> writes:

> On Nov 4, 2004, at 4:32 PM, Richard Henderson wrote:
>
>> On Wed, Nov 03, 2004 at 10:22:53PM -0500, Bradley Lucier wrote:
>>> I glanced at the design document; it seems that many of these changes
>>> could also apply to getting an accurate back-end model of x86
>>> floating-point arithmetic.  Is this part of your goal?
>>
>> Many of them can, yes.  But the biggest hurdle there is convincing
>> reload to spill values in XFmode.
>
> Ah, but one finds in the design document:
>
>> __fpreg is an extended floating point type which provides user
>> access to the full width of the floating point registers. It has the
>> following properties:
>>
>>     * It is copied between registers and memory with 'fill/spill'
>> instructions that transfer the complete internal register content.

It does not make sense to implement __fpreg on an i386.  The register
format of the i387 floating-point stack is a true IEEE extended, as
far as I am aware, not the exotic 82-bit ia64 format.  You've already
got long double on i386.

Also, it wouldn't help.  The problem with spills from the register
stack is that reload has no reason to believe that the value is not a
true SFmode or DFmode quantity, so it issues a truncating store.  (The
ia64 architecture doesn't have this problem because all arithmetic
instructions have the ability to round to single or double after the
operation, so the narrow store doesn't truncate.  Actually, adding
__fpreg, with its passive-conversion behavior, creates a situation
where the problem *can* occur on ia64 - if a float variable has a
passively-converted quantity in it, with more bits of mantissa than it
should, and it gets spilled to memory before use, those extra bits
will be lost.  However, the vast number of registers on ia64 makes
this relatively unlikely to occur in practice.)

> What I don't understand (and what is quite limiting, it seems to me)
> is the reason for the next point:
>
>>     * There is no way to write a constant with type __fpreg.

I didn't write this specification; but there are two adequate reasons
for it.  First is that the internal register format is documented, in
the architecture manual, as subject to change in the future.
Therefore the compiler should not have too much knowledge of what it
is.  Second, in practice, those 82 bits can be filled in just fine
with a __float80 constant -- "L" suffix on Linux, "W" on HPUX with
acc.  (I should maybe see if there's a sane way to add "W" (and "Q")
to gcc.)

zw