Multiple precison shoule be supported by NaN-boxing. That means, we should
flush not valid NaN-boxing input to canonical NaN before effective
calculation and we should NaN-boxing the result after the effective
calculation.

In this patch set, split the implementation to three steps for compute,
sign-injection, and some covert insns, which are check_nanboxed,
effective calculation and gen_nanbox_fpr.

Check_nanboxed checks the inputs and flushes not valid inputs to cancical NaN.
Effective calculation is direct calculation on fp32 values.
Gen_nanbox_fpr does the NaN-boxing, writing the 1s to upper 32 bits.

LIU Zhiwei (6):
  target/riscv: move gen_nanbox_fpr to translate.c
  target/riscv: NaN-boxing compute, sign-injection and convert
    instructions.
  target/riscv: Check for LEGAL NaN-boxing
  target/riscv: check before allocating TCG temps
  target/riscv: Flush not valid NaN-boxing input to canonical NaN
  target/riscv: clean up fmv.w.x

 target/riscv/insn_trans/trans_rvd.inc.c |  16 +-
 target/riscv/insn_trans/trans_rvf.inc.c | 317 +++++++++++++++++++-----
 target/riscv/translate.c                |  43 ++++
 3 files changed, 306 insertions(+), 70 deletions(-)

-- 
2.23.0

On 6/26/20 1:59 PM, LIU Zhiwei wrote:
> Multiple precison shoule be supported by NaN-boxing. That means, we should
> flush not valid NaN-boxing input to canonical NaN before effective
> calculation and we should NaN-boxing the result after the effective
> calculation.
> 
> In this patch set, split the implementation to three steps for compute,
> sign-injection, and some covert insns, which are check_nanboxed,
> effective calculation and gen_nanbox_fpr.
> 
> Check_nanboxed checks the inputs and flushes not valid inputs to cancical NaN.
> Effective calculation is direct calculation on fp32 values.
> Gen_nanbox_fpr does the NaN-boxing, writing the 1s to upper 32 bits.

I know I just reviewed a couple of these, but then I got to thinking about
patch 3 more closely.

I think it would be better to do all of the nan-boxing work inside of the
helpers, including the return values.

Since we must have a helper call for the actual fp arithmetic, we might as well
put the rest of the logic in there too.  That way the JIT code is smaller.

If, for RVF && !RVD, we always maintain the invariant that the values are
nanboxed anyway, then we do not even have to check for RVD at runtime.

Thoughts?


r~

Patchew URL: https://patchew.org/QEMU/20200626205917.4545-1-zhiwei_liu@c-sky.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=c28f1fcf68b949df96a6698f1d098a1e', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-2v7la0ef/src/docker-src.2020-06-26-17.16.29.17531:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=c28f1fcf68b949df96a6698f1d098a1e
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-2v7la0ef/src'
make: *** [docker-run-test-mingw@fedora] Error 2

real    5m18.805s
user    0m9.201s


The full log is available at
http://patchew.org/logs/20200626205917.4545-1-zhiwei_liu@c-sky.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com