Re: [PATCH 00/10] fpu: Remove remaining target ifdefs and build only once

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 21/2/25 14:28, Peter Maydell wrote:
> On Fri, 21 Feb 2025 at 13:05, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>
>> Hi Peter,
>>
>> 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
>>
>> Could you add a preparatory patch passing float_status argument
>> here? This eases the following patch review.
> 
> I could, and in retrospect I agree it would have been a better
> division of patches, but both you and RTH have already reviewed
> patches 4 and 5 in their current form, so is it worth doing now ?

If it isn't too much a burden, I'd prefer to have the extra patches
included. Not for today's review, but for our future readers learning
from the git history (as I'm custom to).

I understand you are waiting RTH's ack on patch #6 to update it and
don't plan to respin. If you agree to split, I suppose it isn't in
your principles to merge a series without posting the final result
on the list. I have the patches locally split so can post as v2 base
if that helps. Otherwise I won't insist, up to your workflow :)

Regards,

Phil.