To eliminate TARGET_AARCH64, we need to make various definitions common
between 32 and 64 bit Arm targets.
Added registers are used only by aarch64 code, and the only impact is on
the size of CPUARMState, and added zarray
(ARMVectorReg zarray[ARM_MAX_VQ * 16]) member (+64KB)

It could be eventually possible to allocate this array only for aarch64
emulation, but I'm not sure it's worth the hassle to save a few KB per
vcpu. Running qemu-system takes already several hundreds of MB of
(resident) memory, and qemu-user takes dozens of MB of (resident) memory
anyway.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
---
 target/arm/cpu.h | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 00f78d64bd8..51b6428cfec 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -175,7 +175,6 @@ typedef struct ARMVectorReg {
     uint64_t d[2 * ARM_MAX_VQ] QEMU_ALIGNED(16);
 } ARMVectorReg;
 
-#ifdef TARGET_AARCH64
 /* In AArch32 mode, predicate registers do not exist at all.  */
 typedef struct ARMPredicateReg {
     uint64_t p[DIV_ROUND_UP(2 * ARM_MAX_VQ, 8)] QEMU_ALIGNED(16);
@@ -185,7 +184,6 @@ typedef struct ARMPredicateReg {
 typedef struct ARMPACKey {
     uint64_t lo, hi;
 } ARMPACKey;
-#endif
 
 /* See the commentary above the TBFLAG field definitions.  */
 typedef struct CPUARMTBFlags {
@@ -656,13 +654,11 @@ typedef struct CPUArchState {
     struct {
         ARMVectorReg zregs[32];
 
-#ifdef TARGET_AARCH64
         /* Store FFR as pregs[16] to make it easier to treat as any other.  */
 #define FFR_PRED_NUM 16
         ARMPredicateReg pregs[17];
         /* Scratch space for aa64 sve predicate temporary.  */
         ARMPredicateReg preg_tmp;
-#endif
 
         /* We store these fpcsr fields separately for convenience.  */
         uint32_t qc[4] QEMU_ALIGNED(16);
@@ -707,7 +703,6 @@ typedef struct CPUArchState {
         uint32_t cregs[16];
     } iwmmxt;
 
-#ifdef TARGET_AARCH64
     struct {
         ARMPACKey apia;
         ARMPACKey apib;
@@ -739,7 +734,6 @@ typedef struct CPUArchState {
      * to keep the offsets into the rest of the structure smaller.
      */
     ARMVectorReg zarray[ARM_MAX_VQ * 16];
-#endif
 
     struct CPUBreakpoint *cpu_breakpoint[16];
     struct CPUWatchpoint *cpu_watchpoint[16];
-- 
2.39.5

On 3/17/25 21:51, Pierrick Bouvier wrote:
> To eliminate TARGET_AARCH64, we need to make various definitions common
> between 32 and 64 bit Arm targets.
> Added registers are used only by aarch64 code, and the only impact is on
> the size of CPUARMState, and added zarray
> (ARMVectorReg zarray[ARM_MAX_VQ * 16]) member (+64KB)
> 
> It could be eventually possible to allocate this array only for aarch64
> emulation, but I'm not sure it's worth the hassle to save a few KB per
> vcpu. Running qemu-system takes already several hundreds of MB of
> (resident) memory, and qemu-user takes dozens of MB of (resident) memory
> anyway.
> 
> Signed-off-by: Pierrick Bouvier<pierrick.bouvier@linaro.org>
> ---
>   target/arm/cpu.h | 6 ------
>   1 file changed, 6 deletions(-)

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

I think this could easily squash with ARM_MAX_VQ, since the
rationale is better spelled out here.


r~

On 3/18/25 15:45, Richard Henderson wrote:
> On 3/17/25 21:51, Pierrick Bouvier wrote:
>> To eliminate TARGET_AARCH64, we need to make various definitions common
>> between 32 and 64 bit Arm targets.
>> Added registers are used only by aarch64 code, and the only impact is on
>> the size of CPUARMState, and added zarray
>> (ARMVectorReg zarray[ARM_MAX_VQ * 16]) member (+64KB)
>>
>> It could be eventually possible to allocate this array only for aarch64
>> emulation, but I'm not sure it's worth the hassle to save a few KB per
>> vcpu. Running qemu-system takes already several hundreds of MB of
>> (resident) memory, and qemu-user takes dozens of MB of (resident) memory
>> anyway.
>>
>> Signed-off-by: Pierrick Bouvier<pierrick.bouvier@linaro.org>
>> ---
>>    target/arm/cpu.h | 6 ------
>>    1 file changed, 6 deletions(-)
> 
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> 
> I think this could easily squash with ARM_MAX_VQ, since the
> rationale is better spelled out here.
> 

Yes, makes sense. I'll squash it.

> 
> r~