On Fri, May 1, 2020 at 10:18 PM Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 5/1/20 6:10 AM, Alex Bennée wrote:
> >
> > 罗勇刚(Yonggang Luo) <luoyongg...@gmail.com> writes:
> >
> >> On Fri, May 1, 2020 at 7:58 PM BALATON Zoltan <bala...@eik.bme.hu>
> wrote:
> >>
> >>> On Fri, 1 May 2020, 罗勇刚(Yonggang Luo) wrote:
> >>>> That's what I suggested,
> >>>> We preserve a float computing cache
> >>>> typedef struct FpRecord {
> >>>> uint8_t op;
> >>>> float32 A;
> >>>> float32 B;
> >>>> } FpRecord;
> >>>> FpRecord fp_cache[1024];
> >>>> int fp_cache_length;
> >>>> uint32_t fp_exceptions;
> >>>>
> >>>> 1. For each new fp operation we push it to the fp_cache,
> >>>> 2. Once we read the fp_exceptions , then we re-compute
> >>>> the fp_exceptions by re-running the fp FpRecord sequence.
> >>>> and clear fp_cache_length.
> >>>
> >>> Why do you need to store more than the last fp op? The cumulative bits
> can
> >>> be tracked like it's done for other targets by not clearing fp_status
> then
> >>> you can read it from there. Only the non-sticky FI bit needs to be
> >>> computed but that's only determined by the last op so it's enough to
> >>> remember that and run that with softfloat (or even hardfloat after
> >>> clearing status but softfloat may be faster for this) to get the bits
> for
> >>> last op when status is read.
> >>>
> >> Yeap, store only the last fp op is also an option. Do you means that
> store
> >> the last fp op,
> >> and calculate it when necessary? I am thinking about a general fp
> >> optmize method that suite
> >> for all target.
> >
> > I think that's getting a little ahead of yourself. Let's prove the
> > technique is valuable for PPC (given it has the most to gain). We can
> > always generalise later if it's worthwhile.
>
> Indeed.
>
> > Rather than creating a new structure I would suggest creating 3 new tcg
> > globals (op, inA, inB) and re-factor the front-end code so each FP op
> > loaded the TCG globals. The TCG optimizer should pick up aliased loads
> > and automatically eliminate the dead ones. We might need some new
> > machinery for the TCG to avoid spilling the values over potentially
> > faulting loads/stores but that is likely a phase 2 problem.
>
> There's no point in new tcg globals.
>
> Every fp operation can raise an exception, and therefore every fp operation
> will flush tcg globals to memory. Therefore there is no optimization to be
> done at the tcg opcode level.
>
> However, every fp operation calls a helper function, and the quickest
> thing to
> do is store the inputs to env->(op, inA, inB, inC) in the helper before
> performing the operation.
>
I thinks there is a possibility to add the tcg ops to optimize the floating
point; For example
WebAssembly doesn't support for float point exception and fp round mode at
all, I suppose most fp execution are no need care about
round mode and fp expcetion, and for this path we can use tcg-op to
abstract it,
and for all other condition we can downgrading to soft-float. As a final
path to optmize to fp accel of
QEMU, we can split the tcg-op into two path. one is hard-float with result
cache for lazy fp flags calculating
And one is pure soft-float path.
For lazy fp flags calculating, cause we have stick flags
```
float_flag_invalid = 1,
float_flag_divbyzero = 4,
float_flag_overflow = 8,
float_flag_underflow = 16,
float_flag_inexact = 32,
```
We can skip the calculation of these flags when these flags are already
marked to 1.
For these five flags, we can split to 5 calculating function, One function
only check one of the flags.
And once the flags are set to 1, then we won't call the functon any more,
unless the flag are cleared.
We will reduce a lot of branch prediction. And the function would only be
called when the
fp flags are requested.
This is my final goal to optimize fp in QEMU, before that, we can do
simpler things to optimize fp in QEMU
And besides these type of optimization, we can also offloading the fp
exception calculating to other CPU core, so
we can making single threading performance be better, cause single core
performance are hard to improve, but multiple core
system are more and more used in these days, for Ryzen 2/ Threadripper we
even have 64-core /128 threads.
>
> > Next you will want to find places that care about the per-op bits of
> > cpu_fpscr and call a helper with the new globals to re-run the
> > computation and feed the values in.
>
> Before we even get to this deferred fp operation thing, there are several
> giant
> improvements to ppc emulation that can be made:
>
> Step 1 is to rearrange the fp helpers to eliminate helper_reset_fpstatus().
> I've mentioned this before, that it's possible to leave the steady-state of
> env->fp_status.exception_flags == 0, so there's no need for a separate
> function
> call. I suspect this is worth a decent speedup by itself.
>
I would like to start the fp optimize from here.
>
> Step 2 is to notice when all fp exceptions are masked, so that no
> exception can
> be raised, and set a tb_flags bit. This is the default fp environment that
> libc enables and therefore extremely common.
>
> Currently, ppc has 3 helpers called per fp operation. If step 1 is handled
> correctly, then we're down to 2 fp helpers per fp operation. If no
> exceptions
> need raising, then we can perform the entire operation with a single
> function call.
>
> We would require a parallel set of fp helpers that (1) performs the
> operation
> and (2) does any post-processing of the exception bits straight away, but
> (3)
> without raising any exceptions. Sort of like helper_fadd +
> do_float_check_status, but less. IIRC the only real extra work is
> categorizing
> invalid exceptions. We could even plausibly extend softfloat to do that
> while
> it is recording the invalid exception.
>
> Step 3 is to improve softfloat.c with Yonggang Luo's idea to compute
> inexact
> from the inverse hardfloat operation. This would let us relax the
> restriction
> of only using hardfloat when we have already have an accrued inexact
> exception.
>
> Only after all of these are done is it worth experimenting with caching the
> last fp operation.
>
>
> r~
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
