From: Paolo Bonzini <pbonzini@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>,
qemu-devel@nongnu.org, aurelien@aurel32.net,
peter.maydell@linaro.org, alex.bennee@linaro.org,
laurent@vivier.eu, rth@twiddle.net, ehabkost@redhat.com
Subject: Re: [PATCH v2 0/6] softfloat, target/i386: fprem, fprem1 fixes
Date: Fri, 12 Jun 2020 18:41:02 +0200 [thread overview]
Message-ID: <eb560234-5bdc-e78a-a9c0-c823839f2010@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2006081653080.23637@digraph.polyomino.org.uk>
On 08/06/20 18:54, Joseph Myers wrote:
> The x87 floating-point emulation of the fprem and fprem1 instructions
> works via conversion to and from double. This is inherently
> unsuitable for a good emulation of any floatx80 operation. This patch
> series adapts the softfloat floatx80_rem implementation to be suitable
> for these instructions and uses it to reimplement them.
>
> There is an existing test for these instructions, test-i386-fprem.c,
> based on comparison of output. It produces 1679695 lines of output,
> and before this patch series 415422 of those lines are different on
> hardware from the output produced by QEMU. Some of those differences
> are because QEMU's x87 emulation does not yet produce the "denormal
> operand" exception; ignoring such differences (modifying the output
> from a native run not to report that exception), there are still
> 398833 different lines. This patch series reduces that latter number
> to 1 (that one difference being because of missing checks for
> floating-point stack underflow, another global issue with the x87
> emulation), or 35517 different lines without the correction for lack
> of denormal operand exception support.
>
> Several fixes to and new features in the softfloat support for this
> operation are needed; floatx80_mod, previously present in the m68k
> code only, is made generic and unified with floatx80_rem in a new
> floatx80_modrem of which floatx80_mod and floatx80_rem are thin
> wrappers. The only architectures using float*_rem for other formats
> are arm (FPA emulation) and openrisc (instructions that have been
> removed in the latest architecture version); they do not appear to
> need any of the new features, and all the bugs fixed are specific to
> floatx80, so no changes are made to the remainder implementation for
> those formats.
>
> A new feature added is returning the low bits of the quotient from
> floatx80_modrem, as needed for both x87 and m68k. The logic used to
> determine the low 7 bits of the quotient for m68k
> (target/m68k/fpu_helper.c:make_quotient) appears completely bogus (it
> looks at the result of converting the remainder to integer, the
> quotient having been discarded by that point); this patch series does
> not change that to use the new interface, but the m68k maintainers may
> wish to do so.
>
> The Intel instruction set documentation leaves unspecified the exact
> number of bits by which the remainder instructions reduce the operand
> each time. The AMD documentation gives a specific formula, which
> empirically Intel processors follow as well, and that formula is
> implemented in the code. The AMD documentation also specifies that
> flags other than C2 are cleared in the partial remainder case, whereas
> the Intel manual is silent on that (but the processors do appear to
> clear those flags); this patch implements that flag clearing, and
> keeps the existing flag clearing in cases where the instructions raise
> "invalid" (although it seems hardware in fact only clears some but not
> all flags in that case, leaving other flags unchanged).
>
> The Intel manuals include an inaccurate table asserting that (finite
> REM 0) should raise "divide by zero"; actually, in accordance with
> IEEE semantics, it raises "invalid". The AMD manuals inaccurately say
> for both fprem and fprem1 that if the exponent difference is negative,
> the numerator is returned unchanged, which is correct (apart from
> normalizing pseudo-denormals) for fprem but not for fprem1 (and the
> old QEMU code had an incorrect optimization following the AMD manuals
> for fprem1).
>
> Changes in version 2 of the patch series: fix comment formatting and
> combine patches 6 and 7.
>
> Joseph Myers (6):
> softfloat: merge floatx80_mod and floatx80_rem
> softfloat: fix floatx80 remainder pseudo-denormal check for zero
> softfloat: do not return pseudo-denormal from floatx80 remainder
> softfloat: do not set denominator high bit for floatx80 remainder
> softfloat: return low bits of quotient from floatx80_modrem
> target/i386: reimplement fprem, fprem1 using floatx80 operations
>
> fpu/softfloat.c | 87 ++++++++++++++++++----
> include/fpu/softfloat.h | 3 +
> target/i386/fpu_helper.c | 156 ++++++++++++---------------------------
> target/m68k/softfloat.c | 83 ---------------------
> target/m68k/softfloat.h | 1 -
> 5 files changed, 122 insertions(+), 208 deletions(-)
>
Queued, thanks.
Paolo
prev parent reply other threads:[~2020-06-12 16:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-08 16:54 [PATCH v2 0/6] softfloat, target/i386: fprem, fprem1 fixes Joseph Myers
2020-06-08 16:55 ` [PATCH v2 1/6] softfloat: merge floatx80_mod and floatx80_rem Joseph Myers
2020-06-08 16:55 ` [PATCH v2 2/6] softfloat: fix floatx80 remainder pseudo-denormal check for zero Joseph Myers
2020-06-08 16:56 ` [PATCH v2 3/6] softfloat: do not return pseudo-denormal from floatx80 remainder Joseph Myers
2020-06-08 16:56 ` [PATCH v2 4/6] softfloat: do not set denominator high bit for " Joseph Myers
2020-06-08 16:57 ` [PATCH v2 5/6] softfloat: return low bits of quotient from floatx80_modrem Joseph Myers
2020-06-08 16:58 ` [PATCH v2 6/6] target/i386: reimplement fprem, fprem1 using floatx80 operations Joseph Myers
2020-06-12 16:41 ` Paolo Bonzini [this message]
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=eb560234-5bdc-e78a-a9c0-c823839f2010@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=aurelien@aurel32.net \
--cc=ehabkost@redhat.com \
--cc=joseph@codesourcery.com \
--cc=laurent@vivier.eu \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).