8341611: [REDO] AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands #22862
+8,495
−369
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
IndOffXX
types don't do us any good. It would be simpler and faster to match a general-purposeIndOff
type then letlegitimize_address()
fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.This patch simplifies the definitions of
immXOffset
with an estimated range. Whether an immediate can be encoded in aLDR
/STR
instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessarylegitimize_address()
in the phase of matcher for allLDR
/STR
instructions using the newIndOff
memory operands (fix JDK-8341437).After this clean-up, memory operands matched with
IndOff
may require extra code emission (effectively alea
) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix JDK-8340646). Onaarch64
platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. BecauseLDR
/STR
is always the last one emitted, no matter what addressing mode the load/store operations finally use.Tier 1 - 3 passed on
Macos-aarch64
with or without the vm option-XX:+UseZGC
.Progress
Issue
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22862/head:pull/22862
$ git checkout pull/22862
Update a local copy of the PR:
$ git checkout pull/22862
$ git pull https://git.openjdk.org/jdk.git pull/22862/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22862
View PR using the GUI difftool:
$ git pr show -t 22862
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22862.diff
Using Webrev
Link to Webrev Comment