RFR: 8319690: [AArch64] C2 compilation hits offset_ok_for_immed: assert "c2 compiler bug" [v3]

[Fei Gao]

On Wed, 29 May 2024 09:51:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is much better. However, I don't think that all the IndOffXX types do us any good. It would be simpler and faster to match a general-purpose IndOff type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time it takes to run them.

Thanks for your review @theRealAph . Matching a general-purpose IndOff type then letting `legitimize_address()` fix any out-of-range operands is an interesting idea and does simplify our code.

Assuming that we have a case like:

data_a = UNSAFE.getLongUnaligned(TestLong.BYTES, 1030);
UNSAFE.putLongUnaligned(BYTES, 1030, data_b);

After matcher, we have:

ldr  R10, [R12, #1030]
str  R11, [R12, #1030]


But `1030` can't be encoded as `base` + `offset` mode, so we need to go to `legitimize_address()`, then we may get:

add	x8, x12, #0x406 // legitimize_address
ldr	x10, [x8]
add	x8, x12, #0x406 // legitimize_address
str	x11, [x8]


We have to re-generate address every time we try to visit the same address. But `IndOff` type in matcher may help us reduce it. What do you think? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16991#issuecomment-2142479156