8370473: C2: Better Aligment of Vector Spill Slots #27969
Draft
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.
With this change c2 will allocate spill slots for vectors with sp offsets aligned to the size of the vectors. Maximum alignment is StackAlignmentInBytes.
It also updates comments that have never been changed to describe how register allocation works for sizes larger than 64 bit.
The change helps to produce better spill code on AARCH64 and PPC64 where an additional add instruction is emitted if the offset of a vector un-/spill is not aligned.
The change is rather a cleanup than an optimization. In most cases the sp offsets will already be properly aligned.
Only with incoming stack arguments unaligned offsets can be generated. But also then alignment padding is only added if vector registers larger than 64 bit are used.
So the costs are effectively zero. Especially because extra padding won't enlarge the frame since only virtual registers are allocated which are mapped to the caller frame (see
pad0in the diagram)There's a risk though that with the extra virtual registers allocated for
pad0the limit of registers aRegMaskcan represent is reached (occurs with excessive spilling). If this happens the compilation would fail. It could be retried with smaller alignment for vector spilling though. I havn't implemented it as I thought the risk is negligible.Note that the sp offset of the accesses should be aligned rather than the effective address. So it could even be argued that the maximum alignment could be higher than StackAlignmentInBytes.
Testing with fastdebug builds on AARCH64 and PPC64:
hotspot_vector_1
hotspot_vector_2
jdk_vector
jdk_vector_sanity
The change passed our CI testing:
Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests.
Testing was done on the main platforms and also on Linux/PPC64le and AIX.
C2 compilation of
jdk.internal.vm.vector.VectorSupport::rearrangeOphas unaligned spill offsets. It is covered by the following tests:compiler/vectorapi/VectorRearrangeTest.java
jdk/incubator/vector/Byte128VectorLoadStoreTests.java
jdk/incubator/vector/Double256VectorLoadStoreTests.java
jdk/incubator/vector/Float128VectorTests.java
jdk/incubator/vector/Long256VectorLoadStoreTests.java
jdk/incubator/vector/Short128VectorLoadStoreTests.java
jdk/incubator/vector/Vector64ConversionTests.java
Progress
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27969/head:pull/27969$ git checkout pull/27969Update a local copy of the PR:
$ git checkout pull/27969$ git pull https://git.openjdk.org/jdk.git pull/27969/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 27969View PR using the GUI difftool:
$ git pr show -t 27969Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27969.diff