Re: About hardfloat in ppc

[BALATON Zoltan]

On Tue, 28 Apr 2020, Alex Bennée wrote:
> 罗勇刚(Yonggang Luo) <address@hidden> writes:
> > I am confusing why only  inexact  are set then we can use hard-float.
>
> The inexact behaviour of the host hardware may be different from the
> guest architecture we are trying to emulate and the host hardware may
> not be configurable to emulate the guest mode.
>
> Have a look in softfloat.c and see all the places where
> float_flag_inexact is set. Can you convince yourself that the host
> hardware will do the same?

Can you convince me that it won't? This all seems to be guessing without 
evidence so I think what we need first is some tests to prove it either 
way. Such tests could then also be used at runtime to decide if the host 
and guest FPU are compatible enough to enable hardfloat. Are such tests 
available somewhere or what would need to be done to implement them?

This may not solve the problem with PPC target with non-cumulative status 
bits but could improve hardfloat performance at least for some host-guest 
combinations. To see if it worth the effort we should run such test on 
common combinations (say x86_64. ARM and PPC hosts with at least these 
guests).

> > And PPC always clearing inexact  flag before calling to soft-float
> > funcitons. so we can not
> > optimize it with hard-float.
> > I need some resouces about ineact flag and why always clearing inexcat in
> > PPC FP simualtion.
>
> Because that is the behaviour of the PPC floating point unit. The
> inexact flag will represent the last operation done.

More precisely additional to the usual cumulative (or sticky) bits there 
are two non-sticky bits for inexact and rounded (latter of which is not 
emulated) that currently need clearing FP status before every FP op. I 
wonder if we can know when the guest reads these and rerun the last FP op 
in softfloat to compute them only if these are read, then it's enough to 
remember the last FP op. This could be relatively simple and may be used 
even if we don't detect accessing the bits within FPSCR just accessing the 
FPSCR as likely most guest code does not check that and any cross-platform 
code won't check PPC specific non-sticky bits so I'd exepect most guest 
code to be fine with hardfloat. Although what about FP exceptions? We also 
need to revert to softfloat it FP exceptions are enabled so maybe using 
host FP exception for managing status bits could be the way to go to let 
hardware manage this and we don't need to implement everything in 
software.

Regards,
BALATON Zoltan