RFR: 8260355: AArch64: deoptimization stub should save vector registers

[Andrew Haley]

On 1/29/21 7:53 AM, Nick Gasson wrote:
> On 01/28/21 17:48 pm, Andrew Haley wrote:
>>
>> It seems to me that save_vectors is only set here:
>>
>>    bool save_vectors = COMPILER2_OR_JVMCI != 0;
>>
>> which means that save_vectors is a static property of a build, not something
>> that can vary. Therefore, there is nothing to be gained by passing save_vectors
>> around. Could we simply have a save_vectors_on_deopt() function?
>>
> 
> RegisterSaver is also used by generate_resolve_blob (which never saves
> vectors) and generate_handler_blob (which saves vectors when poll_type
> == POLL_AT_VECTOR_LOOP). How about we make RegisterSaver a class you can
> instantiate, and pass whether to save vectors or not to the constructor?
> That would look like:
> 
>   RegisterSaver reg_save(COMPILER2_OR_JVMCI != 0 /* save_vectors */);
>   map = reg_save.save_live_registers(masm, 0, &frame_size_in_words);
>   ...
>   reg_save.restore_live_registers(masm);
> 
> Which avoids passing save_vectors around everywhere.

That sounds like a great improvement.

>> Also, I'm wondering how much all of this complexity gains us for the sake
>> of configurations without C2. I'd be very tempted to just leave a hole in
>> the stack for these systems. How much stack would that cost?
> 
> For NEON the difference is 768 bytes vs 512, but SVE could be a lot
> more.

OK, so it probably wouldn't be worth doing on NEON. But A64FX vectors are 64
bytes each, right? So 2kbytes to save, in which case we need this variable-size
register-save area.

>   83 // FIXME -- this is used by C1
>   84 class RegisterSaver {
> 
> Do you remember what this is referring to? That it's duplicating
> save_live_registers() in c1_Runtime_aarch64.cpp?

Probably, yes.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671