qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



      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).