On Wed, 26 Feb 2020, Alex Bennée wrote:
> BALATON Zoltan <balaton@eik.bme.hu> writes:
>> OK, then how about keeping the default accurate but allow to opt in to
>> use FPU even if it's known to break some bits for workloads where
>> users would need speed over accuracy and would be happy to live with
>> the limitation.
>
> About the only comparison I can think of is the thread=single:multi
> flags for TCG which is mostly there to help developers eliminate causes
> of bugs. The default for MTTCG is it is enabled when it's safe. If you
> enable it via the command line where QEMU hasn't defaulted it on you
> will get lots of loud warnings about potential instability. The most
> commonly used case is thread=single when you want to check it's not a
> MTTCG bug.
>
> I'm as cautious as Peter here about adding a "faster but broken" command
> line flag because users will invariably read up to the "faster" and then
> spend a lot of time scratching their heads when things break.

OK understood. However this is specifically about PPC emulation where some 
bits exists in FPSCR that's hard to emulate with hardfloat but until 
recently these weren't correctly emulated in my understanding and things 
still ran OK so it's believed that these bits are seldom used. It was only 
fixed due to some tests revealing it not because of actual negative 
effects seen.

Unfortunately enabling hardfloat without any other changes would make the 
default softfloat case a bit slower so that's why I was asking about also 
making hardfloat case the default.

I can try to try some other approach to avoid always setting inexact bit 
and only keep it set as other archs do but not sure when will I have time 
to get there. Some help in this would be appreciated by those who know PPC 
FPU and interested in running it faster in QEMU.

Regards,
BALATON Zoltan