qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] fpu/softfloat: check for Inf / x or 0 / x befor


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH] fpu/softfloat: check for Inf / x or 0 / x before /0
Date: Fri, 20 Apr 2018 09:20:04 +0100
User-agent: mu4e 1.1.0; emacs 26.1

Richard Henderson <address@hidden> writes:

> On 04/17/2018 01:08 PM, Peter Maydell wrote:
>> On 18 April 2018 at 00:01, Peter Maydell <address@hidden> wrote:
>>> I don't have the original IEEE754 spec to hand though;
>>> that may have left this unspecified.
>>
>> Having located a copy of 754-1985 I think that also is
>> clear enough that float-float conversion is an operation
>> that must quieten SNaN and raise Invalid.
>
> That does seem to match actual processor behaviour.
> The attached test case produces
>
> 7fa00000
> 7ffc000000000000 - 1
> 7ff4000000000000
> 7fe00000 - 1
>
> on both x86_64 and aarch64.
>
> For ppc64, I believe there's a compiler bug:
>
> 7fa00000
> 7ff4000000000000 - 0
> 7ff4000000000000
> 7fe00000 - 536870912
>
> convert float to double:
>     1000074c:   60 00 01 c0     lfs     f0,96(r1)
>     10000750:   68 00 01 d8     stfd    f0,104(r1)
>
> convert double to float:
>     100007a8:   68 00 01 c8     lfd     f0,104(r1)
>     100007ac:   18 00 00 fc     frsp    f0,f0
>     100007b0:   60 00 01 d0     stfs    f0,96(r1)
>
> Floating point numbers are held in a "register" format that largely 
> corresponds
> to double-precision.  Thus the compiler believes that loading a
> single-precision value and then storing it out again as a double is 
> sufficient.
>  However, as we can see above that does not consider SNaN.
>
> There is no ppc "convert single to double" instruction, there is only a "round
> to single precision" instruction -- frsp.  However, if we assume that the
> single precision number is already properly rounded, then we can add an extra
> frsp and it will not normally affect the value at all; it will only change the
> contents for snan.
>
> If I manually add the frsp insn to the code generated for the test case I get
>
> 7fa00000
> 7ffc000000000000 - 536870912
> 7ff4000000000000
> 7fe00000 - 536870912
>
> exactly as we expect.  I'll file a bug vs gcc.

It does seem to be floating point is a rabbit hole that everyone gets
something wrong if you look too closely!

--
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]