[aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

[Erik Österlund]

Hi Ningsheng,

On 2020-08-24 11:59, Ningsheng Jian wrote:
> Hi Erik,
>
> Thanks for the review!
>
> On 8/22/20 12:21 AM, Erik Österlund wrote:
>> Hi,
>>
>> Have you tried this with ZGC on AArch64? It has custom code for saving
>> live registers in the load barrier slow path.
>> I can't see any code changes there, so assuming this will just crash
>> instead.
>> The relevant code is in ZBarrierSetAssembler on aarch64.
>>
>> Maybe I missed something?
>>
>
> I didn't add ZGC option while running tests. I think I need to update 
> push_fp() which is called by ZSaveLiveRegisters. But do we need to get 
> size info (float/neon/sve) instead of saving the whole vector 
> register? Currently, it just simply saves the whole NEON register.

What we found on x86_64 was that there was a significant cost in saving 
vector registers in load barriers. That is why we perform some analysis 
so that only the exact registers that are affected, and only the parts 
of the registers that are affected, get spilled. It actually mattered. 
It will of course work either way, but that was our observation on 
x86_64. But I am okay with that being deferred to a separate RFE. I just 
wanted to make sure that it at the very least works with the new code, 
for a start, so it doesn't start crashing.

> And in ZBarrierSetAssembler::load_at(), before calling to runtime 
> code, we call push_call_clobbered_registers_except(), which just saves 
> floating point registers instead of the whole NEON vector registers. 
> Similar behavior in x86 implementation. Is that correct (not saving 
> vectors)?

Yes. The call contexts are:
1) Interpreter. Does not use vector registers.
2) Method handle intrinsic. Uses only floats that are part of the Java 
calling convention, rest is garbage. No vectors here.
3) Checkcast arraycopy. Does not use vectors.

Thanks,
/Erik

> Thanks,
> Ningsheng