-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8328938: C2 SuperWord: disable vectorization for large stride and scale #18485
Conversation
👋 Welcome back epeter! A progress list of the required criteria for merging this PR into |
@eme64 This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 33 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with that. That's a reasonable, safe and easy solution.
Co-authored-by: Christian Hagedorn <christian.hagedorn@oracle.com>
…me64/jdk into JDK-8328938-abs-min-int-assert
|
if (abs(long_scale) >= max_val || | ||
abs(long_stride) >= max_val || | ||
abs(long_scale * long_stride) >= max_val) { | ||
assert(!valid(), "adr stride*scale is too large"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why you need assert?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you look a few lines up, you can see that all other "bailouts" also check that the VPointer is invalid. I am simply matching the surrounding code. And it also makes it explicit, that the VPointer will be invalid, which is what I want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay
@chhagedorn @vnkozlov thanks for the reviews! |
Going to push as commit 2931458.
Your commit was automatically rebased without conflicts. |
Problem
In JDK-8310190 / https://git.openjdk.org/jdk/pull/14785 I fixed the alignment with
AlignVector
. For that, I had to computeabs(scale)
andabs(stride)
, as well asscale * stride
. The issue is that all of these values can overflow the int range (e.g.abs(min_int) = min_int
).We hit asserts like:
# assert(is_power_of_2(value)) failed: value must be a power of 2: 0xffffffff80000000
Happens because we take
abs(min_int)
, which ismin_int = 0x80000000
, and assuming this was a positive (unsigned) number is a power of 22^31
. We then expand it tolong
, get0xffffffff80000000
, which is not a power of 2 anymore. This violates the implicit assumptions, and we hit the assert.# assert(q >= 1) failed: modulo value must be large enough
We have
scale = 2^30
andstride = 4 = 2^2
. For the alignment calculation we computescale * stride = 2^32
, which overflows the int range and becomes zero.Before JDK-8310190 we could get similar issues with the (old) code in
SuperWord::ref_is_alignable
, ifAlignVector
is enabled:if
span == 0
because of overflow, then theidiv
from the modulo gets a division by zero ->SIGFPE
.But it seems the bug is possibly a regression from JDK20 b2 JDK-8286197. Here we enabled certaint Unsafe memory access address patterns, and it is such patterns that the reproducer requires.
Solution
I could either patch up all the code that works with
scale
andstride
, and make sure no overflows ever happen. But that is quite involved and error prone.I now just disable vectorization for large
scale
andstride
. This should not have any performance impact, because such largescale
andstride
would lead to highly inefficient memory accesses, since they are spaced very far apart.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18485/head:pull/18485
$ git checkout pull/18485
Update a local copy of the PR:
$ git checkout pull/18485
$ git pull https://git.openjdk.org/jdk.git pull/18485/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 18485
View PR using the GUI difftool:
$ git pr show -t 18485
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18485.diff
Webrev
Link to Webrev Comment