Re: [PATCH 1/2] target/arm: Disable VFPv4-D32 when NEON is not available

[Peter Maydell <peter.maydell@linaro.org>]

On Thu, 29 Sept 2022 at 08:20, Cédric Le Goater <clg@kaod.org> wrote:
>
> On 9/29/22 01:00, Joel Stanley wrote:
> > On Wed, 28 Sept 2022 at 16:47, Cédric Le Goater <clg@kaod.org> wrote:
> >> @@ -1684,6 +1684,10 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp)
> >>           cpu->isar.id_isar6 = u;
> >>
> >>           if (!arm_feature(env, ARM_FEATURE_M)) {
> >
> > Can you explain why the test is put behind the !ARM_FEATURE_M check?
>
> Do you mean the setting of MVFR0 ?
>
> because it was close to the code clearing the SIMD bits (NEON)
> of MVFR1 and it seemed more in sync with the specs :
>
>     "When FPU option is selected without NEON, the FPU is VFPv4-D16 and
>      uses 16 double-precision registers. When the FPU is implemented with
>      NEON, the FPU is VFPv4-D32 and uses 32 double-precision registers.
>      This register bank is shared with NEON."
>
> (That said, M processors don't have NEON, so this part of the code
> should never be reached )

They don't have Neon, but that means that cpu->has_neon is
false, so this part of the code *will* be reached. The reason
this sub-part of the "disable Neon" handling is inside
a not-M check is because M-profile has a different assignment
for some of the MVFR1 fields (check the comments in the FIELD
definitions in cpu.h), and zeroing things out based on the
A-profile meanings would be wrong.

thanks
-- PMM