RFR: 8290082: [PPC64] ZGC C2 load barrier stub needs to preserve vector registers [v2]

[Martin Doerr]

On Tue, 12 Jul 2022 07:13:42 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid using more than the volatile program storage (288 Bytes) on stack below the SP.
>
> src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp line 486:
> 
>> 484:         assert(SuperwordUseVSX, "or should not reach here");
>> 485:         VectorSRegister vs_reg = vm_reg->as_VectorSRegister();
>> 486:         if (vs_reg->encoding() >= VSR32->encoding() && vs_reg->encoding() <= VSR51->encoding()) {
> 
> Why VSR32 as lower bound? I read in ppc.ad
> 
> 1st 32 VSRs are aliases for the FPRs wich are already defined above.
> 
> Could you please help and explain what this means?
> 
> Why VSR51 as upper bound?
> 
> I'd suggest to update the comment in register_ppc.hpp and explain the vector scalar registers.
> What is the difference between vector and vector scalar registers?

Thanks for looking at it!
VSRs are not separate registers. They contain the regular FPRs (mapped to 0-31) and VRs (mapped to 32-63). FPRs are managed separately while the VRs are not defined elsewhere in the ppc.ad file. There are instructions which operate on VSRs and can access FPRs and VRs. This was tricky to implement in hotspot ([JDK-8188139](https://bugs.openjdk.org/browse/JDK-8188139) and many follow-up fixes).
Only the VRs VR0-VR19 are volatile (see register_ppc.hpp), so only these ones need spilling. (Same is done for other register types.)
VR0-VR19 = VSR32-VSR51
Note that only these ones are currently used by C2 (see `reg_class vs_reg` in ppc.ad). Reason is that we currently don't preserve the non-volatile ones in the Java entry frame.

-------------

PR: https://git.openjdk.org/jdk/pull/9453