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