Re: [Qemu-devel] [PATCH v6 07/13] fpu: introduce hardfloat

[Emilio G. Cota]

On Sun, Nov 25, 2018 at 01:25:25 +0100, Aleksandar Markovic wrote:
> > Note: some architectures (at least PPC, there might be others) clear
> > the status flags passed to softfloat before most FP operations. This
> > precludes the use of hardfloat, so to avoid introducing a performance
> > regression for those targets, we add a flag to disable hardfloat.
> > In the long run though it would be good to fix the targets so that
> > at least the inexact flag passed to softfloat is indeed sticky.
> 
> Can you elaborate more on this paragraph?

Sure. We only use hardfloat when the inexact flag is already
set. If it isn't, we defer to softfloat. This is done for two
reasons:

- Computing the inexact flag requires duplicating
  most of what softfloat does, so it's not worth doing. Note
  that clearing and reading the host's fp flags is even
  slower, so that's not an option.

- The inexact flag is raised *very* frequently. The flag
  remains set (in the guest) unless guest code explicitly
  clears it, which few guest workloads do.

It therefore makes sense for hardfloat to only kick in once
the inexact flag has already been set.

Most targets directly keep the guest's FP flags in the same
struct (float_status) that is passed to softfloat ops.
PPC, however, keeps the state of the guest FP flags in one
place, and passes a pristine float_status to softfloat code
every time it calls it. Thus, given that hardfloat is
entirely implemented in softfloat.c, PPC targets cannot
currently take advantage of it.

Changing this in the PPC target is not impossible, but it will
require additional work that I'm not doing in this series, hence
my note. So for now, PPC targets just have hardfloat disabled
at compile time, which avoids adding overhead for a feature
that they cannot use.

Let me know if anything is unclear. Cheers,

                Emilio