From: BALATON Zoltan <balaton@eik.bme.hu>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Richard Henderson <richard.henderson@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
John Arbuckle <programmingkidx@gmail.com>,
qemu-ppc <qemu-ppc@nongnu.org>, Paul Clarke <pc@us.ibm.com>,
Howard Spoelstra <hsp.cat7@gmail.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
Date: Fri, 21 Feb 2020 20:52:35 +0100 (CET) [thread overview]
Message-ID: <alpine.BSF.2.22.395.2002212034570.8472@zero.eik.bme.hu> (raw)
In-Reply-To: <CAFEAcA9-VzUXij1_vFr+d7KuMOw+Tdv0hvxW2WmfGxt=fAKvjg@mail.gmail.com>
On Fri, 21 Feb 2020, Peter Maydell wrote:
> On Fri, 21 Feb 2020 at 18:04, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> On Fri, 21 Feb 2020, Peter Maydell wrote:
>>> 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.
>>
>> I don't know of a better approach. Please see section 4.2.2 Floating-Point
>> Status and Control Register on page 124 in this document:
>>
>> https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0
>>
>> especially the definition of the FR and FI bits and tell me how can we
>> emulate these accurately and use host FPU.
>
> I don't know much about PPC, but if you can't emulate the
> guest architecture accurately with the host FPU, then
> don't use the host FPU. We used to have a kind of 'hardfloat'
I don't know if it's possible or not to emulate these accurately and use
the FPU but nobody did it for QEMU so far. But if someone knows a way
please speak up then we can try to implement it. Unfortunately this would
require more detailed knowledge about different FPU implementations (at
least X86_64, ARM and PPC that are the mostly used platforms) than what I
have or willing to spend time to learn.
> support that was fast but inaccurate, but it was a mess
> because it meant that most guest code sort of worked but
> some guest code would confusingly misbehave. Deliberately
> not correctly emulating the guest CPU/FPU behaviour is not
> something I want us to return to.
>
> You're right that sometimes you can't get both speed
> and accuracy; other emulators (and especially ones
> which are trying to emulate games consoles) may choose
> to prefer speed over accuracy. For QEMU we prefer to
> choose accuracy over speed in this area.
OK, then how about keeping the default accurate but allow to opt in to use
FPU even if it's known to break some bits for workloads where users would
need speed over accuracy and would be happy to live with the limitation.
Note that i've found that just removing the define that disables hardfloat
for PPC target makes VMX vector instructions faster while normal FPU is a
little slower without any other changes so disabling hardfloat already
limits performance for guests using VMX even when not using the FPU for
cases when it would cause inaccuracy. If you say we want accuracy and
don't care about speed, then just don't disable hardfloat as it helps at
least VMX and then we can add option to allow the user to say we can use
hardfloat even if it's inaccurate then they can test their workload and
decide for themselves.
Regards,
BALATON Zoltan
next prev parent reply other threads:[~2020-02-21 19:53 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 17:10 [RFC PATCH v2] target/ppc: Enable hardfloat for PPC BALATON Zoltan
2020-02-18 17:38 ` BALATON Zoltan
2020-02-19 2:27 ` Programmingkid
2020-02-19 15:35 ` BALATON Zoltan
2020-02-19 18:28 ` Howard Spoelstra
2020-02-19 19:28 ` BALATON Zoltan
2020-02-20 5:43 ` Howard Spoelstra
2020-02-25 3:07 ` Programmingkid
2020-02-25 12:09 ` BALATON Zoltan
2020-02-26 10:46 ` Programmingkid
2020-02-26 11:28 ` BALATON Zoltan
2020-02-26 13:00 ` R: " luigi burdo
2020-02-26 13:08 ` Dino Papararo
2020-02-26 14:28 ` Alex Bennée
2020-02-26 15:50 ` Aleksandar Markovic
2020-02-26 17:04 ` G 3
2020-02-26 17:27 ` Aleksandar Markovic
2020-02-26 18:14 ` R: " Dino Papararo
2020-02-26 18:51 ` Aleksandar Markovic
2020-02-27 2:43 ` Programmingkid
2020-02-27 7:16 ` Aleksandar Markovic
2020-02-27 11:54 ` BALATON Zoltan
2020-02-26 18:09 ` R: " Alex Bennée
2020-03-02 0:13 ` Programmingkid
2020-03-02 4:28 ` Richard Henderson
2020-03-02 11:42 ` BALATON Zoltan
2020-03-02 16:55 ` Richard Henderson
2020-03-02 23:16 ` BALATON Zoltan
2020-03-03 0:11 ` Richard Henderson
[not found] ` <CAKyx-3Pt2qLPXWQjBwrHn-nxR-9e++TioGp4cKFC3adMN3rtiw@mail.gmail.com>
2020-03-04 18:43 ` Fwd: " G 3
2020-03-05 19:25 ` Richard Henderson
2020-03-02 17:10 ` Alex Bennée
2020-03-02 23:01 ` BALATON Zoltan
2020-02-26 22:51 ` R: " BALATON Zoltan
2020-02-20 20:13 ` Richard Henderson
2020-02-21 16:04 ` BALATON Zoltan
2020-02-21 16:11 ` Peter Maydell
2020-02-21 16:51 ` Aleksandar Markovic
2020-02-21 18:04 ` BALATON Zoltan
2020-02-21 18:26 ` Peter Maydell
2020-02-21 19:52 ` BALATON Zoltan [this message]
2020-02-26 12:28 ` Alex Bennée
2020-02-26 13:07 ` BALATON Zoltan
2020-04-10 13:50 ` 罗勇刚(Yonggang Luo)
2020-04-10 18:04 ` BALATON Zoltan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.BSF.2.22.395.2002212034570.8472@zero.eik.bme.hu \
--to=balaton@eik.bme.hu \
--cc=david@gibson.dropbear.id.au \
--cc=hsp.cat7@gmail.com \
--cc=pc@us.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).