Re: [Qemu-devel] [RFC] target-ppc/fpu_helper.c: Use C99 code to speed up floating point unit

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

On 12/03/2016 07:32 PM, Richard Henderson wrote:
> On 12/03/2016 09:07 AM, Programmingkid wrote:
>> Yes it would be. The commit message never stated why he wanted to switch
>> to floating point softfloat routines. These are my guesses:
> ...
>> - Different hosts produced different results and instead wanted
>> consistency?
> 
> This is the correct answer.  There are quite a lot of differences
> between floating point across different cpus.  Which means that it's
> actually rare that the host and guest floating point are exactly alike.

Or to frame it in different words:

qemu's goal is to be an architecturally-accurate emulator.  fma() has
specific C99 semantics (mapping to what IEEE floating point requires),
but USUALLY those semantics are not fully implemented in hardware;
rather, the hardware implements 90% and has specific flags or traps that
let the C library recognize when it has to manually perform the 10% of
special cases. But the special cases differ by hardware.

If all hardware implemented C99 semantics 100% of the time, then using
C99 to emulate hardware would be correct.  But since that is not true,
emulating C99 semantics instead of hardware semantics will be WRONG in
the special cases, and cause programs to misbehave under qemu where they
would behave correctly on bare metal. So the decision was that accurate
emulation (guaranteed by using soft-float operations that are tailored
to each hardware's specific quirks on the special cases) is more
important that speed (where the behavior can be different from hardware
on the special cases, even if that behavior is accurate to IEEE and C99
semantics).

If you can completely describe ALL special cases that ANY particular
platform has quirks for, and kick to softmmu for those cases while still
sticking to C99 for the common cases, you may have success. But at this
point, I doubt you have properly identified all the quirks where native
fma instructions differ from C99 fma() requirements, let alone the
differences in emulation that will be required to properly quirk all
possible floating point hardware.  And it's not even guaranteed that
identifying all the inputs that need special casing for various guest
hardware, before calling out to fma() in the remainder of cases, will
not slow things down (since fma() will have its own set of additional
quirking conditionals based on host hardware).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]