ghost
commented
2 years ago Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch See info in area-owners.md if you want to be subscribed.
Issue Details
Platforms like Arm32 and Arm64 have a dedicated "zero register" and this means that zero is nearly always easily and trivially accessible to codegen. Platforms like x86 and x64 however do not directly expose the concept of a zero register and instead support the concept internally via the register renamer which is not exposed to assembly. Due to using SIMD to zero stack locals and the frequent need to use or compare against zero in many functions, it is often the case that at least one register is zeroed. On the other hand, not many functions are complex enough to utilize all 16 of a given set of registers. Because of this, I believe it would be beneficial at least on x64 (where 16 general purpose and 16 SIMD registers are available, this jumps to ~32 SIMD registers for AVX-512) to "soft reserve" a register to represent zero. The register allocator would have special support for assigning zero into this register and for making it the "least preferenced" register for other values (therefore it is likely the last caller save register) to ensure it can stay zero for as long as possible. For most methods, this will ensure we initialize no more than once for each register kind and in the off-chance it needs to be "spilled", we do not actually have to incur the cost of storing the value to the stack and can trivially reconstitute it when the call returns. For methods which use many registers, there will ideally be no overall difference to what is generated today as the desired register will be unavailable and so it will fall back to whatever is available instead. This may also be profitable on x86, but given it has half the number registers (8 general purpose and 8 SIMD regardless of AVX2 or AVX-512 support), this likely needs more testing and consideration than x64.
| Author: | tannergooding |
|---|---|
| Assignees: | - |
| Labels: | `area-CodeGen-coreclr` |
| Milestone: | - |
tannergooding
kunalspathak
EgorBo
huoyaoyuan
Platforms like Arm64 have a dedicated "zero register" and this means that zero is nearly always easily and trivially accessible to codegen. Platforms like Arm32, x86 and x64 however do not directly expose the concept of a zero register. x86 and x64 in particular instead support the concept internally via the register renamer which is not exposed to assembly. Likewise Arm64 doesn't have a dedicated zero register for SIMD even though one for general purpose registers does exist.
Due to using SIMD to zero stack locals and the frequent need to use or compare against zero in many functions, it is often the case that at least one register is zeroed. On the other hand, not many functions are complex enough to utilize all 16 of a given set of registers. Because of this, I believe it would be beneficial at least on x64 (where 16 general purpose and 16 SIMD registers are available, this jumps to ~32 SIMD registers for AVX-512) to "soft reserve" a register to represent zero. The register allocator would have special support for assigning zero into this register and for making it the "least preferenced" register for other values (therefore it is likely the last caller save register) to ensure it can stay zero for as long as possible.
For most methods, this will ensure we initialize no more than once for each register kind and in the off-chance it needs to be "spilled", we do not actually have to incur the cost of storing the value to the stack and can trivially reconstitute it when the call returns. For methods which use many registers, there will ideally be no overall difference to what is generated today as the desired register will be unavailable and so it will fall back to whatever is available instead.
This may also be profitable on x86, but given it has half the number registers (8 general purpose and 8 SIMD regardless of AVX2 or AVX-512 support), this likely needs more testing and consideration than x64.
category:proposal theme:register-allocator