Re: [Qemu-devel] Future of SoftFloat use in QEMU

[Richard Henderson]

On 05/08/2017 07:58 AM, Alex Bennée wrote:
> Hi,
>
> We've got a task coming up to implement half-precision floating point
> (FP16) for ARMv8.2. As you know pretty much all our floating point in
> QEMU is handled by our internal fork of John R. Hauser's BSD SoftFloat
> library. Our current implementation is based on version 2a which doesn't
> support FP16.
>
> As it happens there has been a new release of SoftFloat recently.
> Version 3 is a complete re-write which made a number of changes, some
> notable ones being:
>
>    - Complete rewrite, different use license than earlier releases.
>    - Renaming most types and functions, upgrading some algorithms
>      - restructuring the source files, and making SoftFloat into a true library.

But also now using thread-local globals instead of passing in a structure with 
all of the parameters.  So, really, we'd probably wind up touching every 
function if we were to import it.

> So what else can we do?
>
> We could investigate having both libraries included in QEMU. It seems
> the API has changed quite a bit so that might be possible although there
> would be hackage involved in having two different softfloat.h's
> involved.
>
> This would be useful if we wanted to take a piecemeal approach to
> updating the library. For example we could just use softfloat3 when we
> need the newer features (e.g. FP16).
>
> Or we could convert one architecture at a time so each qemu binary links
> against either a version 2 or version 3 softfloat library. Of course
> that does run the risk of permanently holding two versions of softfloat
> in the code if the less maintained guest architectures don't convert
> quickly.

Another possibility is the code that's shared between the linux kernel 
(include/math-emu) and glibc (soft-fp).  The glibc version has support for f16 
while the kernel doesn't.  But the glibc version is LGPL 2.1, which I'd expect 
to be ok.

It is mildly nasty in that it's a collection of macros, but that's how we 
managed really good performance with the compiler tech of 15 years ago.  On the 
other hand, it would be fairly easy to adjust the support macros to achive 
source compatibility with our current code.

Just a thought...


r~