RFR: 8260355: AArch64: deoptimization stub should save vector registers [v2]

[Nick Gasson]

On Thu, 28 Jan 2021 12:12:32 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> For Arm NEON (and PPC) we don't set VMReg::next() in oopmap either, and their vector slots are contiguous, so that's x86-specific? But yes, NEON can also generate correct full oopmap as for fixed vector size. For SVE, I have no idea to have proper VMReg::next() support, so Nick's solution looks good to me. Regarding to introducing new cross-platform API, which API do you mean? If we could have some better api, that would be perfect. Currently, allocate_vector_payload_helper() is the only one I can see that is vector related for RegisterMap::location() call.
>
> Probably, x86 is unique in using non-contiguous representation for vector values, but it doesn't make the code in question x86-specific. AArch64 is the only user of`VecA` and `VecA` is the only register type that has a mismatch in size between in-memory and RegMask representation. So, I conclude it is AArch64/SVE-specific.
> 
> On x86 RegisterMap isn't fully populated for vector registers as well, but there's`RegisterMap::pd_location()` to cover that.
> 
> Regarding new API, I mean the alternative to `VMReg::next()`/`RegisterMap::location(VMReg)` which is able to handle `VecA` case well. As Nick pointed out earlier, the problem with `VecA` is that there's no `VMReg` representation for all the slots which comprise the register value. 
> 
> Either enhancing `VMReg::next(int)` to produce special values for `VecA` case or introducing `RegisterMap::location(VMReg base_reg, int slot)` is a better way to handle the problem.

@iwanowww please take a look at the latest set of changes and let me know what you think. There's now a `RegisterMap::location(VMReg base_reg, int slot)` method as you suggest. That in turn uses a new method `VMReg::is_expressible(int slot_delta)` which is true if offsetting a VMReg by slot_delta slots gives another valid VMReg which is also a slot of the same physical register (i.e. `reg->next(slot_delta)` is valid). We can use this to fall back to `pd_location` if a slot of a vector is not expressible as a VMReg (i.e. for SVE). Unfortunately it touches a lot of files but that seems unavoidable.

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

PR: https://git.openjdk.java.net/jdk/pull/2279