[master] RFR: Fix loading Klass* in C1 on AArch64

Roman Kennke rkennke at openjdk.java.net
Fri Jan 21 16:59:08 UTC 2022


On Fri, 21 Jan 2022 14:47:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This doesn't look right. There's no point saving anything in res, because it may well just get clobbered by `Runtime1::load_klass_id`. Like Aleksey, I can't see why forcing res into `r0` won't work.

I agree, and I would prefer to register-allocate res in r0. I tried that, and it works in most cases, but unfortunately C1 fails to do that correctly in this code sequence:
https://github.com/openjdk/lilliput/blob/master/src/hotspot/share/gc/shared/c1/barrierSetC1.cpp#L337

The reason for that is (according to @rwestrel) that the code sequence contains control flow inside a single basic block (which is borderline illegal, and we kinda lucky that it doesn't blow up), and that confuses the register allocator and would end up clobbering some other value. Fixing this would require to rewrite that code sequence to either emit several basic blocks and stitch together the control flow correctly. I don't really want to go there :-)

What I'm doing instead is allocate res freely, and then shuffle registers accordingly in the backend. What I'm doing here is this:
1. If res is allocated in r0 we don't have a problem at all, and don't need to do anything.
2. Else, I swap r0 and res. This preserves the original contents of r0 in res, which will be preserved around the call. This frees r0 for use as argument and result register.
3. After the call, I swap r0 and res again: This brings the result into res, and restores the original value of r0 from res (which has been push/popped around the call).

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

PR: https://git.openjdk.java.net/lilliput/pull/34


More information about the lilliput-dev mailing list