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
signature.asc
Description: OpenPGP digital signature