diff mbox series

[02/13] target/arm: Add isar_feature_any_fp16 and document naming/usage conventions

Message ID 20200211173726.22541-3-peter.maydell@linaro.org
State Superseded
Headers show
Series arm: Implement ARMv8.1-PMU and ARMv8.4-PMU | expand

Commit Message

Peter Maydell Feb. 11, 2020, 5:37 p.m. UTC
Our current usage of the isar_feature feature tests almost always
uses an _aa32_ test when the code path is known to be AArch32
specific and an _aa64_ test when the code path is known to be
AArch64 specific. There is just one exception: in the vfp_set_fpscr
helper we check aa64_fp16 to determine whether the FZ16 bit in
the FP(S)CR exists, but this code is also used for AArch32.
There are other places in future where we're likely to want
a general "does this feature exist for either AArch32 or
AArch64" check (typically where architecturally the feature exists
for both CPU states if it exists at all, but the CPU might be
AArch32-only or AArch64-only, and so only have one set of ID
registers).

Introduce a new category of isar_feature_* functions:
isar_feature_any_foo() should be tested when what we want to
know is "does this feature exist for either AArch32 or AArch64",
and always returns the logical OR of isar_feature_aa32_foo()
and isar_feature_aa64_foo().

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

---
 target/arm/cpu.h        | 19 ++++++++++++++++++-
 target/arm/vfp_helper.c |  2 +-
 2 files changed, 19 insertions(+), 2 deletions(-)

-- 
2.20.1

Comments

Richard Henderson Feb. 11, 2020, 6:28 p.m. UTC | #1
On 2/11/20 9:37 AM, Peter Maydell wrote:
> Our current usage of the isar_feature feature tests almost always

> uses an _aa32_ test when the code path is known to be AArch32

> specific and an _aa64_ test when the code path is known to be

> AArch64 specific. There is just one exception: in the vfp_set_fpscr

> helper we check aa64_fp16 to determine whether the FZ16 bit in

> the FP(S)CR exists, but this code is also used for AArch32.

> There are other places in future where we're likely to want

> a general "does this feature exist for either AArch32 or

> AArch64" check (typically where architecturally the feature exists

> for both CPU states if it exists at all, but the CPU might be

> AArch32-only or AArch64-only, and so only have one set of ID

> registers).

> 

> Introduce a new category of isar_feature_* functions:

> isar_feature_any_foo() should be tested when what we want to

> know is "does this feature exist for either AArch32 or AArch64",

> and always returns the logical OR of isar_feature_aa32_foo()

> and isar_feature_aa64_foo().

> 

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> ---

>  target/arm/cpu.h        | 19 ++++++++++++++++++-

>  target/arm/vfp_helper.c |  2 +-

>  2 files changed, 19 insertions(+), 2 deletions(-)


Reviewed-by: Richard Henderson <richard.henderson@linaro.org>



r~
Philippe Mathieu-Daudé Feb. 12, 2020, 6:24 a.m. UTC | #2
On 2/11/20 6:37 PM, Peter Maydell wrote:
> Our current usage of the isar_feature feature tests almost always

> uses an _aa32_ test when the code path is known to be AArch32

> specific and an _aa64_ test when the code path is known to be

> AArch64 specific. There is just one exception: in the vfp_set_fpscr

> helper we check aa64_fp16 to determine whether the FZ16 bit in

> the FP(S)CR exists, but this code is also used for AArch32.

> There are other places in future where we're likely to want

> a general "does this feature exist for either AArch32 or

> AArch64" check (typically where architecturally the feature exists

> for both CPU states if it exists at all, but the CPU might be

> AArch32-only or AArch64-only, and so only have one set of ID

> registers).

> 

> Introduce a new category of isar_feature_* functions:

> isar_feature_any_foo() should be tested when what we want to

> know is "does this feature exist for either AArch32 or AArch64",

> and always returns the logical OR of isar_feature_aa32_foo()

> and isar_feature_aa64_foo().


Good idea.

> 

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> ---

>   target/arm/cpu.h        | 19 ++++++++++++++++++-

>   target/arm/vfp_helper.c |  2 +-

>   2 files changed, 19 insertions(+), 2 deletions(-)

> 

> diff --git a/target/arm/cpu.h b/target/arm/cpu.h

> index ad2f0e172a7..ac4b7950166 100644

> --- a/target/arm/cpu.h

> +++ b/target/arm/cpu.h

> @@ -3400,7 +3400,16 @@ extern const uint64_t pred_esz_masks[4];

>    * Naming convention for isar_feature functions:

>    * Functions which test 32-bit ID registers should have _aa32_ in

>    * their name. Functions which test 64-bit ID registers should have

> - * _aa64_ in their name.

> + * _aa64_ in their name. These must only be used in code where we

> + * know for certain that the CPU has AArch32 or AArch64 respectively

> + * or where the correct answer for a CPU which doesn't implement that

> + * CPU state is "false" (eg when generating A32 or A64 code, if adding

> + * system registers that are specific to that CPU state, for "should

> + * we let this system register bit be set" tests where the 32-bit

> + * flavour of the register doesn't have the bit, and so on).

> + * Functions which simply ask "does this feature exist at all" have

> + * _any_ in their name, and always return the logical OR of the _aa64_

> + * and the _aa32_ function.

>    */

>   

>   /*

> @@ -3702,6 +3711,14 @@ static inline bool isar_feature_aa64_bti(const ARMISARegisters *id)

>       return FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, BT) != 0;

>   }

>   

> +/*

> + * Feature tests for "does this exist in either 32-bit or 64-bit?"

> + */

> +static inline bool isar_feature_any_fp16(const ARMISARegisters *id)

> +{

> +    return isar_feature_aa64_fp16(id) || isar_feature_aa32_fp16_arith(id);

> +}

> +

>   /*

>    * Forward to the above feature tests given an ARMCPU pointer.

>    */

> diff --git a/target/arm/vfp_helper.c b/target/arm/vfp_helper.c

> index 0ae7d4f34a9..930d6e747f6 100644

> --- a/target/arm/vfp_helper.c

> +++ b/target/arm/vfp_helper.c

> @@ -185,7 +185,7 @@ uint32_t vfp_get_fpscr(CPUARMState *env)

>   void HELPER(vfp_set_fpscr)(CPUARMState *env, uint32_t val)

>   {

>       /* When ARMv8.2-FP16 is not supported, FZ16 is RES0.  */

> -    if (!cpu_isar_feature(aa64_fp16, env_archcpu(env))) {

> +    if (!cpu_isar_feature(any_fp16, env_archcpu(env))) {


So we had a potential bug on aa32?

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>


>           val &= ~FPCR_FZ16;

>       }

>   

>
Peter Maydell Feb. 12, 2020, 11:32 a.m. UTC | #3
On Wed, 12 Feb 2020 at 06:24, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>

> On 2/11/20 6:37 PM, Peter Maydell wrote:

> > @@ -185,7 +185,7 @@ uint32_t vfp_get_fpscr(CPUARMState *env)

> >   void HELPER(vfp_set_fpscr)(CPUARMState *env, uint32_t val)

> >   {

> >       /* When ARMv8.2-FP16 is not supported, FZ16 is RES0.  */

> > -    if (!cpu_isar_feature(aa64_fp16, env_archcpu(env))) {

> > +    if (!cpu_isar_feature(any_fp16, env_archcpu(env))) {

>

> So we had a potential bug on aa32?


No, because right now we don't support AA32 FP16 yet (so
the aa32_fp16_arith check is temporarily testing an AA64
ID reg, as noted in a TODO comment in that function), and
anyway all our CPUs which have ARMv8 features also mandatorily
have AArch64 currently. This is mainly tidyup so we are in
a position to add a new v8-32-bit-only CPU if we want to.

thanks
--- PMM
diff mbox series

Patch

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index ad2f0e172a7..ac4b7950166 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -3400,7 +3400,16 @@  extern const uint64_t pred_esz_masks[4];
  * Naming convention for isar_feature functions:
  * Functions which test 32-bit ID registers should have _aa32_ in
  * their name. Functions which test 64-bit ID registers should have
- * _aa64_ in their name.
+ * _aa64_ in their name. These must only be used in code where we
+ * know for certain that the CPU has AArch32 or AArch64 respectively
+ * or where the correct answer for a CPU which doesn't implement that
+ * CPU state is "false" (eg when generating A32 or A64 code, if adding
+ * system registers that are specific to that CPU state, for "should
+ * we let this system register bit be set" tests where the 32-bit
+ * flavour of the register doesn't have the bit, and so on).
+ * Functions which simply ask "does this feature exist at all" have
+ * _any_ in their name, and always return the logical OR of the _aa64_
+ * and the _aa32_ function.
  */
 
 /*
@@ -3702,6 +3711,14 @@  static inline bool isar_feature_aa64_bti(const ARMISARegisters *id)
     return FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, BT) != 0;
 }
 
+/*
+ * Feature tests for "does this exist in either 32-bit or 64-bit?"
+ */
+static inline bool isar_feature_any_fp16(const ARMISARegisters *id)
+{
+    return isar_feature_aa64_fp16(id) || isar_feature_aa32_fp16_arith(id);
+}
+
 /*
  * Forward to the above feature tests given an ARMCPU pointer.
  */
diff --git a/target/arm/vfp_helper.c b/target/arm/vfp_helper.c
index 0ae7d4f34a9..930d6e747f6 100644
--- a/target/arm/vfp_helper.c
+++ b/target/arm/vfp_helper.c
@@ -185,7 +185,7 @@  uint32_t vfp_get_fpscr(CPUARMState *env)
 void HELPER(vfp_set_fpscr)(CPUARMState *env, uint32_t val)
 {
     /* When ARMv8.2-FP16 is not supported, FZ16 is RES0.  */
-    if (!cpu_isar_feature(aa64_fp16, env_archcpu(env))) {
+    if (!cpu_isar_feature(any_fp16, env_archcpu(env))) {
         val &= ~FPCR_FZ16;
     }