On Fri, Feb 21, 2020 at 5:11 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Fri, 21 Feb 2020 at 16:05, BALATON Zoltan <bala...@eik.bme.hu> wrote: > > > > On Thu, 20 Feb 2020, Richard Henderson wrote: > > > On 2/18/20 9:10 AM, BALATON Zoltan wrote: > > >> + DEFINE_PROP_BOOL("hardfloat", PowerPCCPU, hardfloat, true), > > > > > > I would also prefer a different name here -- perhaps x-no-fp-fi. > > > > What's wrong with hardfloat? That's how the code refers to this so if > > anyone searches what it does would turn up some meaningful results. > > This prompted me to check what you're using the property for. > The cover letter says: > > This patch implements a simple way to keep the inexact flag set for > > hardfloat while still allowing to revert to softfloat for workloads > > that need more accurate albeit slower emulation. (Set hardfloat > > property of CPU, i.e. -cpu name,hardfloat=false for that.) > > I think that is the wrong approach. Enabling use of the host > FPU should not affect the accuracy of the emulation, which > should remain bitwise-correct. We should only be using the > host FPU to the extent that we can do that without discarding > accuracy. As far as I'm aware that's how the hardfloat support > for other guest CPUs that use it works. >
Right, that is my understanding as well. There shouldn't be "hardfloat" switch at all. If there is, it is either a mistake, or for experimental or other similar purposes. In my understanding, hardfloat feature should work entirely transparently, making the decision whether to use host math functions (instead of softfloat library) by itself, based on the particular execution circumstances. In other words, the accuracy of FP emulation should not be compromised in absolutely any case (there should not be an option "ok, we are happy with approximate calculations"). On top of that, artificial generating of "inexact" flag really seems problematic (or, speaking bluntly, looks like a hack)). Perhaps hardfloat feature needs a little bit of more work, but not in this way. Yours, Aleksandar > thanks > -- PMM >