From: Richard Henderson <richard.henderson@linaro.org>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: "Dino Papararo" <skizzato73@msn.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
Programmingkid <programmingkidx@gmail.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"Howard Spoelstra" <hsp.cat7@gmail.com>,
"luigi burdo" <intermediadc@hotmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Aleksandar Markovic" <aleksandar.m.mail@gmail.com>,
"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC
Date: Mon, 2 Mar 2020 08:55:38 -0800 [thread overview]
Message-ID: <d136165f-46c7-8983-9725-2b224742deef@linaro.org> (raw)
In-Reply-To: <alpine.BSF.2.22.395.2003021218180.72848@zero.eik.bme.hu>
On 3/2/20 3:42 AM, BALATON Zoltan wrote:
>> The "hardfloat" option works (with other targets) only with ieee745
>> accumulative exceptions, when the most common of those exceptions, inexact, has
>> already been raised. And thus need not be raised a second time.
>
> Why exactly it's done that way? What are the differences between IEEE FP
> implementations that prevents using hardfloat most of the time instead of only
> using it in some (although supposedly common) special cases?
While it is possible to read the host's ieee exception word after the hardfloat
operation, there are two reasons that is undesirable:
(1) It is *slow*. So slow that it's faster to run the softfloat code instead.
I thought it would be easier to find the benchmark numbers that Emilio
generated when this was tested, but I can't find it.
(2) IEEE has a number of implementation choices for corner cases, and we need
to implement the target's choices, not the host's choices.
> I think CPUs can also raise exceptions when they detect the condition in
> hardware so maybe we should install our FPU exception handler and set guest
> flags from that then we don't need to check and won't have problem with these
> bits either. Why is that not possible or isn't done?
If we have to enable and disable host fpu exceptions going in and out of
softfloat routines, we're back to modifying the host fpu control word, which as
described above, is *slow*.
> That handler could only
> set a global flag on each exception that targets can be checked by targets and
> handle differences. This global flag then can include non-sticky versions if
> needed because clearing a global should be less expensive than clearing FPU
> status reg. But I don't really know, just guessing, somone who knows more about
> FPUs probably knows a better way.
I don't know if anyone has tried that variant, where we simply leave the
exceptions enabled, leave the signal handler enabled, and use a global.
Feel free to try it and benchmark it.
r~
next prev parent reply other threads:[~2020-03-02 16:56 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 [this message]
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
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=d136165f-46c7-8983-9725-2b224742deef@linaro.org \
--to=richard.henderson@linaro.org \
--cc=aleksandar.m.mail@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=balaton@eik.bme.hu \
--cc=david@gibson.dropbear.id.au \
--cc=hsp.cat7@gmail.com \
--cc=intermediadc@hotmail.com \
--cc=programmingkidx@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=skizzato73@msn.com \
/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).