Re: [Qemu-devel] [PATCH] softfloat: roundAndPackFloat16 should return FPInfinity and FPMaxNormal based on overflow_to_inf.

[Peter Maydell <peter.maydell@linaro.org>]

On 12 February 2015 at 06:25, Xiangyu Hu <xiangyu.a.hu@gmail.com> wrote:
> On Wed, Feb 11, 2015 at 5:23 AM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
>>
>> On 9 February 2015 at 14:56, Xiangyu Hu <libhu.so@gmail.com> wrote:
>> > Flag overflow_to_inf is specified by ARM manual to decide if
>> > FPInfinity(sign) or FPMaxNormal(sign) is returned. Current
>> > codepath fails to check it.
>> > Fixed by adding overflow_to_inf flag to return infinity when it's
>> > true and maxnormal otherwise.
>>
>> I agree that this is wrong, but I think we want to fix it by
>> making roundAndPackFloat16 work more similarly to the
>> roundAndPackFloat32 and 64 functions...
>
>
> Yes. Actually, a lot of single/double_to_half instructions would lead to
> inconsistent errors
> when calling roundAndPackFloat16. This fix on FPMaxNormal/FPInfinity
> handling
> only recover some of them. Failure to justify "round_up" flag described in
> the manual
> exposed other bugs.

I'm not surprised there are other bugs lurking here.

> I had another implementation that completely followed manual's FPRound(),
> which
> brought no failed cases at all.

I'd prefer to fix the bugs we have rather than totally
reimplement, though (especially since the ARM ARM pseudocode
tends to assume things like infinite-precision floating
point types; it's not always a great model to copy).

> I wonder where current algrithm of roundAndPackFloat16 comes from?

It was added ages ago as part of supporting the ARM 16-bit
fp types; upstream softfloat doesn't have any 16-bit fp
support.

-- PMM