RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands

[Andrew Haley]

On Mon, 7 Oct 2024 09:03:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Let's backout [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) for now, given [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646) and [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437). Backout applies cleanly.
>> 
>> Thanks,
>> Tobias
>
> Oh dear. it's a shame I never got to see the bug report at the time it was filed, but it was just marked as a C2 bug.
> The right thing to do, I think, is to make the segfault handler code a bit smarter. We'll need to go through the process again, with the original fix.

> Hi @theRealAph, note that there are other concerns about [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) besides risk of implicit null check bugs, see https://bugs.openjdk.org/browse/JDK-8340646?focusedId=14709872&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14709872.

I see. However, the root cause of the problem is assumptions elsewhere that output code has a particular sequence of instructions, surely? There are many ways that AArch64 can address the same memory, and there has never been any guarantee that a particular sequence of instructions will be used. We already know that C2 will generate either `ldr r1 [reg, offset]` or `add r2, reg,offset; ldr r1 [r2]`, or many other possibilities. This is all normal stuff that an optimizing compiler does.

Sure, if we have a particular pattern that must do something special that needs to generate an exact known sequence of instructions, we can handle it separately from general memory accesses.

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

PR Comment: https://git.openjdk.org/jdk/pull/21381#issuecomment-2396467211