Re: [RFC PATCH 0/2] Enable hardfloat for PPC

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

On Mon, 17 Feb 2020 at 02:43, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> Hello,
>
> This is an RFC series to start exploring the possibility of enabling
> hardfloat for PPC target that haven't progressed in the last two years.
> Hopefully we can work out something now. Previously I've explored this
> here:
>
> https://lists.nongnu.org/archive/html/qemu-ppc/2018-07/msg00261.html
>
> where some ad-hoc benchmarks using lame mp3 encoder is also explained
> that has two versions: one using VMX and another only using FP. Both
> are mostly floating point bounded. I've run this test on mac99 under
> MorphOS before and after my patches, also verifying that md5sum of
> resulting mp3 matches (this is no proof for correctness but maybe
> shows it did not break too much at least those ops used by this
> program).

> I hope others can contribute to this by doing more testing to find out
> what else this would break or give some ideas how this could be
> improved.

I think the ideal would be to test against a reference using
risu to see whether this changes behaviour (FP results should
be bit-for-bit identical; usually application level testing is
often not sufficient to detect this). You could test either
against real hardware or against the non-hardfloat QEMU.
I'm not sure how comprehensive the coverage for ppc insns
is but there are a fair number of fp insns covered already:
https://git.linaro.org/people/peter.maydell/risu.git/tree/

It's also worth testing any alternate/non-standard config
modes the FPU might have (eg different default rounding modes,
any flush-to-zero or alternate denormal handling, that kind
of thing), and not just the default how-the-CPU-boots-up mode.

thanks
-- PMM