RFR: 8300253: Introduce AArch64 nzcv accessors

[Erik Österlund]

On Tue, 17 Jan 2023 18:50:18 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Could @fisk provide an example of where this might be used?
>> My assumption is that you are looking to execute code verification within, say, a GC memory barrier, and the code has been inserted in between where the condition codes might have been set and then used. This could avoid breaking the existing code when the verification code itself sets the condition codes.
>> It's not all of the pstate, but then this is just userspace, so it ought to be ok?
>
>> Could @fisk provide an example of where this might be used?
>> 
>> My assumption is that you are looking to execute code verification within, say, a GC memory barrier, and the code has been inserted in between where the condition codes might have been set and then used. This could avoid breaking the existing code when the verification code itself sets the condition codes.
>> 
>> It's not all of the pstate, but then this is just userspace, so it ought to be ok?
>> 
>> 
> 
> Your guess is spot on. We have a bunch of GC barrier nodes in C1, and C1 sprinkles oop verification all over the place - including when spilling oops between lir ops - sometimes between producing a condition code and consuming it. So I figured the verification code shouldn't really alter the state of execution such that it does something different. And I don't really want to reduce the amount of verification, because it was very useful in tracking down bugs.

The specific use case we have is here: https://github.com/openjdk/zgc/blob/c23bd9e059df2759adaa5d316ec7d269ef5154a6/src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp#L119

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

PR: https://git.openjdk.org/jdk/pull/12038