On Wed, Feb 26, 2020 at 3:29 PM Alex Bennée <
address@hidden> wrote:
>
>
> Dino Papararo <
address@hidden> writes:
>
> > Please let's go with hardfloat pps support, it's really a good feature to implement.
> > Even if in a first step it could lead to inaccuracy results, later it
> > could solved with other patches.
>
> That's the wrong way around. We have regression tests for a reason.
I tend to agree with Alex here, and additionally want to expand more on
this topic.
In my view: (that I think is at least very close to the community consensus)
This is *not* a ppc-specific issue. There exist a principle across all targets
that QEMU FPU calculation must be accurate - exactly as specified in any
applicable particular ISA document. Any discrepancy is an outright bug.
We even recently had several patches for FPU in ppc target that handled
some fairly obscure cases of inaccuracies, I believe they were authored
by Paul Clarke, so there are people in ppc community that care about
FPU accuracy (as I guess is the case for any target).
There shouldn't be a target that decides by itself and within itself
"ok, we don't need accuracy, let's trade it for speed". This violates
the architecture of QEMU. Please allow that for any given software
project, there is an architecture that should be respected.
This doesn't mean that anybody's experimentation is discouraged. No-one
can stop anybody from forking from QEMU upstream tree and do whatever
is wanted.
But, this doesn't mean such experimentation will be upstreamed. QEMU
upstream should be collecting place for the best ideas and implementations,
not for arbitrary experimentations.
Best regards,
Aleksandar
> I'll happily accept patches to turn on hardfloat for PPC if:
>
> a) they don't cause regressions in our fairly extensive floating point
> tests
> b) the PPC maintainers are happy with the new performance profile
>
> The way forward would be to:
>
> 1. patch to drop #if defined(TARGET_PPC) || defined(__FAST_MATH__)
> 2. audit target/ppc/fpu_helper.c w.r.t chip manual and fix any unneeded
> splatting of flags (if any)
> 3. measure the before/after performance effect and decide if on balance
> it's worth keeping
>
> > I think it's important for qemu to as global as possible and don't
> > target only recent hardware.
>
> Are you referring to guests or hosts? For guests we will always favour
> accuracy of speed of emulation. For hosts we need to have IEEE compliant
> FPU HW to even stand a chance of using hardfloat.
>
> --
> Alex Bennée
>