-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8295407: C2 crash: Error: ShouldNotReachHere() in multiple vector tests with -XX:-MonomorphicArrayCheck -XX:-UncommonNullCast #11034
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
Conversation
…ts with -XX:-MonomorphicArrayCheck -XX:-UncommonNullCast For unsupported `CMove` patterns, JDK-8293833 helps remove unused `CMove` and related packs from superword candidate packset by the function `remove_cmove_and_related_packs()`, but it only works when `-XX:+UseVectorCmov` is enabled[1]. When the option is not enabled, these unsupported `CMove` packs are still kept in the superword packset, causing the same failure. Actually, the function `filter_packs()` in superword is to filter out unsupported packs but it can't work as expected currently for these `CMove` cases. As we know, not all `CMove` packs can be vectorized. `merge_packs_to_cmovd()`[2] looks through all packs in the superword packset and generates a `CMove` candidate packset to collect all qualified `CMove` packs. Hence, only `CMove` packs in the `CMove` candidate packset are our target patterns and can be vectorized. But `filter_packs()` thinks, if the `CMove` pack is in a superword packset and its vector node is implemented in the current platform, then it can be vectorized. Therefore, the function doesn't remove these unsupported packs. We can adjust the function `implemented()` in the stage of `filter_packs()` to check if the current `CMove` pack is in the `CMove` candidate packset. If not, `filter_packs()` considers it not to be vectorized and then remove it. After the fix, whether `-XX:+UseVectorCmov` is enabled or not, these unsupported packs can be removed by `filter_packs()`. In this way, we don't need the function`remove_cmove_and_related_packs()` anymore and thus the patch also cleans related code. [1] https://github.com/openjdk/jdk/blob/9b9be88bcaa35c89b6915ff0c251e5a04b10b330/src/hotspot/share/opto/superword.cpp#L537 [2] https://github.com/openjdk/jdk/blob/9b9be88bcaa35c89b6915ff0c251e5a04b10b330/src/hotspot/share/opto/superword.cpp#L1892 [3] https://github.com/openjdk/jdk/blob/9b9be88bcaa35c89b6915ff0c251e5a04b10b330/src/hotspot/share/opto/superword.cpp#L2701
👋 Welcome back fgao! A progress list of the required criteria for merging this PR into |
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.
Looks good to me otherwise but someone more familiar with superword should look at this as well.
* @test | ||
* @bug 8295407 | ||
* @summary C2 crash: Error: ShouldNotReachHere() in multiple vector tests with | ||
* -XX:-MonomorphicArrayCheck -XX:-UncommonNullCast |
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.
MonomorphicArrayCheck
and UncommonNullCast
are debug flags, the test will fail with a release build.
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.
@TobiHartmann, thanks for your review! The options added here is commented as part of summary title, not as JVM options. I suppose it should be fine for a release build, right? :-)
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.
Right, I missed that. Does the test reproduce the issue without these flags? In any case, I think a more descriptive summary would be good.
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.
Yes, the added testcase here can reproduce the issue even without these flags and I suppose those flags help C2 vectorize more hot loops in the reported testcases. I updated the summary part in the new commit. Thanks for your suggestion @TobiHartmann!
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.
Great, thanks for confirming and updating the summary!
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 have request since you are touching this code.
8192846 changes were a little sloppy and did not rename some methods which causing confusion.
Please, rename is_CmpD_candidate
, merge_packs_to_cmpd
and others you find to general fp
as you did with is_cmove_fo_opcode
.
Or may be simply remove |
Do we have IR tests to verify cmove vectorization? |
@vnkozlov, thanks for point it out. I cleaned up related code and comments in the new commit. Could you please help review it? Thanks!
Yes, we do. I added compiler/c2/irTests/TestVectorConditionalMove.java in JDK-8289422. |
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.
Looks good. I submitted testing.
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.
Looks good to me. Let's wait for Vladimir's testing to finish.
@fg1417 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 70 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. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@TobiHartmann, @vnkozlov) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
I got 2 failures. Description in the bug report. One could be not related. But Vector512ConversionTests.java test failure with flags from the bug report is suspicious. |
Digging in JBS shows that Vector512ConversionTests.java failure is most likely JDK-8276064. So it is not new failure. Looks like your changes are fine. |
Thanks for your kind review and test work, @TobiHartmann @vnkozlov. I'll integrate it. /integrate |
/sponsor |
Going to push as commit cc44419.
Your commit was automatically rebased without conflicts. |
For unsupported
CMove
patterns, JDK-8293833 helps remove unusedCMove
and related packs from superword candidate packset by the functionremove_cmove_and_related_packs()
, but it only works when-XX:+UseVectorCmov
is enabled[1]. When the option is not enabled, these unsupportedCMove
packs are still kept in the superword packset, causing the same failure.Actually, the function
filter_packs()
in superword is to filter out unsupported packs but it can't work as expected currently for theseCMove
cases. As we know, not allCMove
packs can be vectorized.merge_packs_to_cmovd()
[2] looks through all packs in the superword packset and generates aCMove
candidate packset to collect all qualifiedCMove
packs. Hence, onlyCMove
packs in theCMove
candidate packset are our target patterns and can be vectorized. Butfilter_packs()
thinks, if theCMove
pack is in a superword packset and its vector node is implemented in the current platform, then it can be vectorized. Therefore, the function doesn't remove these unsupported packs.We can adjust the function
implemented()
in the stage offilter_packs()
to check if the currentCMove
pack is in theCMove
candidate packset. If not,filter_packs()
considers it not to be vectorized and then remove it. After the fix, whether-XX:+UseVectorCmov
is enabled or not, these unsupported packs can be removed byfilter_packs()
. In this way, we don't need the functionremove_cmove_and_related_packs()
anymore and thus the patch also cleans related code.[1]
jdk/src/hotspot/share/opto/superword.cpp
Line 537 in 9b9be88
[2]
jdk/src/hotspot/share/opto/superword.cpp
Line 1892 in 9b9be88
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11034/head:pull/11034
$ git checkout pull/11034
Update a local copy of the PR:
$ git checkout pull/11034
$ git pull https://git.openjdk.org/jdk pull/11034/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 11034
View PR using the GUI difftool:
$ git pr show -t 11034
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11034.diff