> On 8/26/19 1:28 PM, BALATON Zoltan wrote:
>> On Mon, 26 Aug 2019, Richard Henderson wrote:
>>> That said, qemu-system-ppc64 will *never* use hardfloat, because ppc always
>>> need the current and correct result of inexact for emulation of the FI bit,
>>> which requires that we use the softfloat path.
>>
>> That's bad news. I hoped that hardfloat for PPC can be implemented and
>> previously it was thought it could be done after some reorganisation to prevent
>> always reseting flags by moving them to environment or somewhere else (but I
>> don't remember the details and maybe I never fully understood it in the first
>> place). Could you please explain why do you think it's not possible?
>
> We only use hardfloat if we do not need to compute whether the current
> operation produces an inexact exception. We need not care when the sticky
> inexact bit is already set.
>
> However, for ppc, the FPSCR[FI] bit indicates whether the previous fp operation
> was inexact. Thus we need to compute the inexact exception for every single
> operation.
Is there a way tell qemu "I don't care about FPSCR[FI], so use hardfloat" ?
If not, should there be?
PC
I second that idea. There is a lot of software that only cares about the result of a floating point operation and not the flags it set in the FPSCR. Before my FPSCR[FI] patch, software running in qemu-system-ppc did not seem to have any issues with not having the FI bit ever set. The speed vs accuracy situation should be decided by the user.
This feature would solve this problem:
qemu-system-ppc -use-hardfloat