[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH v5 00/13] hardfloat
From: |
Emilio G. Cota |
Subject: |
[Qemu-devel] [PATCH v5 00/13] hardfloat |
Date: |
Sat, 13 Oct 2018 19:19:20 -0400 |
v4: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg02960.html
Changes since v4:
- Rebase on current master (a73549f99).
- Add a patch for fp-test to pick a specialization; this gets rid of
the muladd errors, since our default "no specialization" does not
raise invalid when one of the muladd inputs is a nan.
- fp-bench: add -r flag to set rounding mode. Do not support "odd"
as an option though, because few ops support it.
- fp-bench: use -o mulAdd instead of -o fma for muladd, to
be consistent with fp-test.
- fp-bench: Use get_clock() instead of get_clock_realtime,
which on unix will use the monotonic clock, if available.
Thus, link fp-bench against libqemuutil (get_clock reads
the use_rt_clock variable, which is provided by
qemu-timer-common.o).
- Do not remove the "flatten" attribute from the softfloat
primitives. Removing it reduces code size, but hurts execution time
(slowdown 2 to 3x) when the rounding mode != even.
Instead, keep the attribute so that !even ops run at a reasonable
speed.
Note that this speed is still a little slower (up to 12% slower
with fp-bench) than before hardfloat, due to the checks
at the beginning of hardfloat functions:
flush_to_zero_if_needed();
if (rounding != even) {
return softfloat();
}
but I suspect we can live with that.
If this were to be an issue in the future, we could use an "ops"
struct with function pointers to just call the right function
(in)directly. I am not doing that here because that would
require that all modifications of .float_rounding_mode go through
set_rounding_mode(), so that the function pointers can be updated.
Let me know if you feel strongly about this -- I did a quick
test with an ops struct for f32_add and it does indeed bringt
the slowdown for !even ops to 0%.
This series introduces no regressions to fp-test. You can test
hardfloat by passing "-f x" to fp-test (so that the inexact flag
is set before each operation) and using even rounding (fp-test's
default). Note that hardfloat does not affect any other rounding
mode.
Perf numbers for fp-bench running on several host machines are in
each commit log; numbers for several benchmarks (NBench, SPEC06fp)
are in the last patch's commit log.
You can fetch this series from:
https://github.com/cota/qemu/tree/hardfloat-v5
Thanks,
Emilio
- [Qemu-devel] [PATCH v5 00/13] hardfloat,
Emilio G. Cota <=
- [Qemu-devel] [PATCH v5 05/13] softfloat: add float{32, 64}_is_zero_or_normal, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 01/13] fp-test: pick TARGET_ARM to get its specialization, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 04/13] softfloat: rename canonicalize to sf_canonicalize, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 03/13] target/tricore: use float32_is_denormal, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 02/13] softfloat: add float{32, 64}_is_{de, }normal, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 10/13] hardfloat: implement float32/64 division, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 09/13] hardfloat: implement float32/64 multiplication, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 07/13] fpu: introduce hardfloat, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 06/13] tests/fp: add fp-bench, Emilio G. Cota, 2018/10/13
- [Qemu-devel] [PATCH v5 08/13] hardfloat: implement float32/64 addition and subtraction, Emilio G. Cota, 2018/10/13