[aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support
Ningsheng Jian
ningsheng.jian at arm.com
Tue Aug 25 10:13:14 UTC 2020
Hi Erik,
On 8/24/20 11:26 PM, Erik Österlund wrote:
> 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.
>
OK, I will make it to save the whole reg in this patch and have a
separate RFE to optimize as what x86 does.
>> 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 for sharing this.
Thanks,
Ningsheng
More information about the build-dev
mailing list