RFR: 8299327: Allow super late barrier expansion of store barriers in C2

Erik Österlund eosterlund at openjdk.org
Tue Jan 10 09:08:55 UTC 2023


On Mon, 9 Jan 2023 15:22:18 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> ZGC uses super late barrier expansion for load barriers in C2. Generational ZGC needs to do the same thing but for store barriers.
>
> src/hotspot/cpu/aarch64/aarch64.ad line 7976:
> 
>> 7974: %{
>> 7975:   match(Set mem (StoreP mem src));
>> 7976:   predicate(n->as_Store()->barrier_data() == 0);
> 
> Why does the instruction below (`storeimmP0_volatile`) not require a similar predicate? Just checking - I guess the omission is intentional since it follows from the ZGC repo.

No, you are right - it does need a similar predicate. The storeimmP0_volatile rule seems to be quite recent, and I wrote this code before it existed and then we must have merged without noticing. Nice catch!

> src/hotspot/cpu/ppc/ppc.ad line 6538:
> 
>> 6536: 
>> 6537: // Store Pointer
>> 6538: instruct storeP(memoryAlg4 dst, iRegPsrc src) %{
> 
> The ADLC peephole replacement logic is not barrier data-aware as far as I can see. I wonder if barrier data is propagated correctly by peephole rules like the one in https://github.com/openjdk/jdk/blob/17a3f0e2577f2f9eb3fe62a4b8261e3dbe4c3b28/src/hotspot/cpu/ppc/ppc.ad#L14877-L14881. But I guess this is a question for PPC maintainers.

Indeed. @TheRealMDoerr would you mind having a look at this?

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

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


More information about the hotspot-compiler-dev mailing list