I am confusing why only inexact are set then we can use hard-float. And PPC always clearing inexact flag before calling to soft-float funcitons. so we can not optimize it with hard-float. I need some resouces about ineact flag and why always clearing inexcat in PPC FP simualtion. I am looking for two possible solution: 1. do not clear inexact flag in PPC simulation 2. even the inexact are cleared, we can still use alternative hard-float.
But now I am the beginner, Have no clue about all the things. On Mon, Apr 27, 2020 at 7:10 PM Alex Bennée <alex.ben...@linaro.org> wrote: > > BALATON Zoltan <bala...@eik.bme.hu> writes: > > > On Mon, 27 Apr 2020, Alex Bennée wrote: > >> 罗勇刚(Yonggang Luo) <luoyongg...@gmail.com> writes: > >>> Because ppc fpu-helper are always clearing float_flag_inexact, > >>> So is that possible to optimize the performance when > float_flag_inexact > >>> are cleared? > >> > >> There was some discussion about this in the last thread about enabling > >> hardfloat for PPC. See the thread: > >> > >> Subject: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC > >> Date: Tue, 18 Feb 2020 18:10:16 +0100 > >> Message-Id: <20200218171702.979f0746...@zero.eik.bme.hu> > > > > I've answered this already with link to that thread here: > > > > On Fri, 10 Apr 2020, BALATON Zoltan wrote: > > : Date: Fri, 10 Apr 2020 20:04:53 +0200 (CEST) > > : From: BALATON Zoltan <bala...@eik.bme.hu> > > : To: "罗勇刚(Yonggang Luo)" <luoyongg...@gmail.com> > > : Cc: qemu-devel@nongnu.org, Mark Cave-Ayland, John Arbuckle, > qemu-...@nongnu.org, Paul Clarke, Howard Spoelstra, David Gibson > > : Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC > > : > > : On Fri, 10 Apr 2020, 罗勇刚(Yonggang Luo) wrote: > > :> Are this stable now? I'd like to see hard float to be landed:) > > : > > : If you want to see hardfloat for PPC then you should read the > > replies to : this patch which can be found here: > > : > > : http://patchwork.ozlabs.org/patch/1240235/ > > : > > : to understand what's needed then try to implement the solution with > > FP : exceptions cached in a global that maybe could work. I won't be > > able to : do that as said here: > > : > > : https://lists.nongnu.org/archive/html/qemu-ppc/2020-03/msg00006.html > > : > > : because I don't have time to learn all the details needed. I think : > > others are in the same situation so unless somebody puts in the : > > necessary effort this won't change. > > > > Which also had a proposed solution to the problem that you could try > > to implement, in particular see this message: > > > > > http://patchwork.ozlabs.org/project/qemu-devel/patch/20200218171702.979f0746...@zero.eik.bme.hu/#2375124 > > > > amd Richard's reply immediately below that. In short to optimise FPU > > emulation we would either find a way to compute inexact flag quickly > > without reading the FPU status (this may not be possible) or somehow > > get status from the FPU but the obvious way of claring the flag and > > reading them after each operation is too slow. So maybe using > > exceptions and only clearing when actually there's a change could be > > faster. > > > > As to how to use exceptions see this message in above thread: > > > > https://lists.nongnu.org/archive/html/qemu-ppc/2020-03/msg00005.html > > > > But that's only to show how to hook in an exception handler what it > > does needs to be implemented. Then tested and benchmarked. > > > > I still don't know where are the extensive PPC floating point tests to > > use for checking results though as that was never answered. > > Specifically for PPC we don't have them. We use the softfloat test cases > to exercise our softfloat/hardfloat code as part of "make > check-softfloat". You can also re-build fp-bench for each guest target > to measure raw throughput. > > >> However in short the problem is if the float_flag_inexact is clear you > >> must use softfloat so you can properly calculate the inexact status. We > >> can't take advantage of the inexact stickiness without loosing the > >> fidelity of the calculation. > > > > I still don't get why can't we use hardware via exception handler to > > detect flags for us and why do we only use hardfloat in some corner > > cases. If reading the status is too costly then we could mirror it in > > a global which is set by an FP exception handler. Shouldn't that be > > faster? Is there a reason that can't work? > > It would work but it would be slow. Almost every FP operation sets > the inexact flag so it would generate an exception and exceptions take > time to process. > > For the guests where we use hardfloat operations with inexact already > latched is not a corner case - it is the common case which is why it > helps. > > > > > Regards, > > BALATON Zoltan > > > -- > Alex Bennée > -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
