On Mon, 17 Feb 2020 at 02:43, BALATON Zoltan <bala...@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
