Message ID | 20230630122551.21766-1-anjo@rev.ng (mailing list archive) |
---|---|
Headers | show |
Series | Collapse CPUNegativeOffsetState into CPUState | expand |
On 6/30/23 14:25, Anton Johansson via wrote: > CPUNegativeOffsetState is a struct placed immediately before > CPUArchState in the ArchCPU struct. Its purpose is to ensure that > certain fields (CPUTLBDescFast, IcountDecr) lay within a small negative > offset of CPUArchState in memory. This is desired for better > code-generation on arm[32|64] and riscv hosts which has addressing > modes with 12- and 11 bits of displacement respectively. The purpose is also to ensure that general purpose registers stay close to the beginning of the CPUArchState and thus can also be accessed with a small displacement. Can you check if this becomes worse for any architecture? On some 64-bit targets, 8 bytes * 32 registers is 512 bytes and it's a substantial part of the 11 bits that are available. Paolo
On 7/1/23 11:21, Paolo Bonzini wrote: > On 6/30/23 14:25, Anton Johansson via wrote: >> CPUNegativeOffsetState is a struct placed immediately before >> CPUArchState in the ArchCPU struct. Its purpose is to ensure that >> certain fields (CPUTLBDescFast, IcountDecr) lay within a small negative >> offset of CPUArchState in memory. This is desired for better >> code-generation on arm[32|64] and riscv hosts which has addressing >> modes with 12- and 11 bits of displacement respectively. > > The purpose is also to ensure that general purpose registers stay > close to the beginning of the CPUArchState and thus can also be > accessed with a small displacement. > > Can you check if this becomes worse for any architecture? On some > 64-bit targets, 8 bytes * 32 registers is 512 bytes and it's a > substantial part of the 11 bits that are available. > > Paolo > I'm dropping the CPUNegativeOffsetState changes, but the fields would still have had a negative displacement from the beginning of env, so the positive offset of the gprs from env wouldn't be affected.