Re: [PATCH v1 11/11] target/arm: Enable BFloat16 extensions

[Richard Henderson]

On 5/18/21 7:47 AM, Richard Henderson wrote:
> On 5/18/21 7:47 AM, Peter Maydell wrote:
> > > diff --git a/target/arm/cpu_tcg.c b/target/arm/cpu_tcg.c
> > > index 046e476f65..b2463cf109 100644
> > > --- a/target/arm/cpu_tcg.c
> > > +++ b/target/arm/cpu_tcg.c
> > > @@ -968,6 +968,7 @@ static void arm_max_initfn(Object *obj)
> > >           t = FIELD_DP32(t, ID_ISAR6, FHM, 1);
> > >           t = FIELD_DP32(t, ID_ISAR6, SB, 1);
> > >           t = FIELD_DP32(t, ID_ISAR6, SPECRES, 1);
> > > +        t = FIELD_DP32(t, ID_ISAR6, BF16, 1);
> > >           cpu->isar.id_isar6 = t;
> > >
> > >           t = cpu->isar.mvfr1;
> >
> > Same query as with SVE: do we need to clear these in the "!has_vfp"
> > and "!has_neon" handling code in arm_cpu_realizefn() ?
>
> I *think* we want to clear ID_ISAR6 only when !has_vfp && !has_neon, as 
> FEAT_AA32BF16 should still be usable to the other one.  Which also means adding 
> the NEON/VFP check you suggested.

Alternately, we can clear BF16 when either !vfp or !neon, and then we don't 
have to add the extra checks.

Unless we're presented with a real cpu that has vfp but not neon, and does have 
bf16, this seems like a head-scratcher corner case.  Just so long as we don't 
do something actively against the rules I guess we're ok.


r~