RFR: 8260355: AArch64: deoptimization stub should save vector registers
Nick Gasson
nick.gasson at arm.com
Fri Jan 29 07:53:19 UTC 2021
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.
> 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.
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?
--
Thanks,
Nick
More information about the hotspot-dev
mailing list