Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

[BALATON Zoltan]

On Sun, 1 Mar 2020, Richard Henderson wrote:
> On 3/1/20 4:13 PM, Programmingkid wrote:
> > Ok, I was just looking at Intel's x87 chip documentation. It supports 
> > IEEE 754 floating point operations and exception flags. This leads me 
> > to this question. Would simply taking the host exception flags and 
> > using them to set the PowerPC's FPU's flag be an acceptable solution to 
> > this problem?

In my understanding that's what is currently done, the problem with PPC as 
Richard said is the non-sticky versions of some of these bits which need 
clearing FP exception status before every FPU op which seems to be 
expensive and slower than using softfloat. So to use hardfloat we either 
accept that we can't emulate these bits with hardfloat or we need to do 
something else than clearing flags and checking after every FPU op.

While not emulating these bits don't seem to matter for most clients and 
other PPC emulations got away with it, QEMU prefers accuracy over speed 
even for rarely used features.

> No.
>
> The primary issue is the FPSCR.FI flag.  This is not an accumulative bit, per
> ieee754, but per operation.
>
> The "hardfloat" option works (with other targets) only with ieee745
> accumulative exceptions, when the most common of those exceptions, inexact, has
> already been raised.  And thus need not be raised a second time.

Why exactly it's done that way? What are the differences between IEEE FP 
implementations that prevents using hardfloat most of the time instead of 
only using it in some (although supposedly common) special cases?

> Per the PowerPC architecture, inexact must be recognized afresh for every
> operation.  Which is cheap in hardware but expensive in software.
>
> And once you're done with FI, FR has been and continues to be emulated 
> incorrectly.

I think CPUs can also raise exceptions when they detect the condition in 
hardware so maybe we should install our FPU exception handler and set 
guest flags from that then we don't need to check and won't have problem 
with these bits either. Why is that not possible or isn't done? The 
softfloat code has a comment that working with exceptions is not pleasent 
but why? Isn't setting flags from a handler easier than checking 
separately for each op? If this is because of differences in how flags are 
handled by different targets we don't have to do that from the host FPU 
exception handler. That handler could only set a global flag on each 
exception that targets can be checked by targets and handle differences. 
This global flag then can include non-sticky versions if needed because 
clearing a global should be less expensive than clearing FPU status reg. 
But I don't really know, just guessing, somone who knows more about FPUs 
probably knows a better way.

Regards,
BALATON Zoltan