On Fri, 21 Feb 2025 at 14:41, Philippe Mathieu-Daudé <phi...@linaro.org> wrote: > > On 17/2/25 13:50, Peter Maydell wrote: > > > (1) floatx80 behaviours > > > > Two QEMU targets implement floatx80: x86 and m68k. (PPC also has one > > use in the xsrqpxp round-to-80-bit-precision operation, and the > > Linux-user NWFPE emulation nominally supports it, but these are > > minor.) x86 and m68k disagree about some of the corner cases of > > floatx80 where the value has the explicit Integer bit wrongly set. At > > the moment the fpu code defaults to "floatx80 behaves like x86", with > > TARGET_M68K ifdefs to get the other option. > > > > The first six patches in this series remove those ifdefs, replacing > > them with a floatx80_behaviour field in float_status which can have > > various flags set to select the individual behaviours. The default is > > "like x86", which allows us to set these only for m68k and not worry > > about the minor "technically makes some use of floatx80" cases. > > > > Peter Maydell (10): > > fpu: Make targets specify floatx80 default Inf at runtime > > target/m68k: Avoid using floatx80_infinity global const > > target/i386: Avoid using floatx80_infinity global const > > Bothering again, we can add the floatx80_default_inf() refactor as the > first patch:
I really think at this point this is just doing extra work shuffling code changes between patches for no real benefit. The patches aren't super huge and they've already been reviewed. I'm OK with splitting out the "add the status argument" part as you suggested previously, as that makes the patches more reasonably split between "just mechanical" and "interesting change" which is not a big split to do and could be helpful for potential bisection later, but churning the patchset beyond that doesn't seem worthwhile to me. -- PMM
