8309204: Obsolete DoReserveCopyInSuperWord#16022
8309204: Obsolete DoReserveCopyInSuperWord#16022eme64 wants to merge 5 commits intoopenjdk:masterfrom
Conversation
… DoReserveCopyInSuperWord
|
👋 Welcome back epeter! A progress list of the required criteria for merging this PR into |
Webrevs
|
vnkozlov
left a comment
There was a problem hiding this comment.
Very nice cleanup. Looks good.
TobiHartmann
left a comment
There was a problem hiding this comment.
Looks good to me otherwise.
Co-authored-by: Tobias Hartmann <tobias.hartmann@oracle.com>
|
@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 41 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 |
|
Thanks @vnkozlov for the help, thanks @TobiHartmann for the review, and thanks @jddarcy for the CSR approval! |
|
Going to push as commit 1ed9c76.
Your commit was automatically rebased without conflicts. |
I'm removing
CountedLoopReserveKitas discussed in #14168 (JDK-8308917).I'm also obsolating
DoReserveCopyInSuperWord, as it has now no use any more.Context
During
SuperWord, we first analyze the loop, do all profitability and correctness checks for vectorization, and only inSuperWord::outputdo we finally modify the C2 graph.However, there could still be some cases where we fail during graph modification. At that point, we have already done some modifications, and now have the followoing options:
ShouldNotReachHere, or simply SIGSEGV because ofnullptraccess etc.)With JDK-8136725 (115afda) option 2 was chosen. We make a copy of the whole loop, and if we chose to abort vectorization we would swap in the unmodified copy. It was primarily used for cases where asserts fail (in debug), and in product instead revert to the unmodified copy. The disadvantage to this approach is that we are requiring the cloning/copying of all superword-ed loops - and none of them are really expected to fail and use the copy. There were some additional cases where we had to revert for post-loop-vectorization, but this was recently removed anyway (JDK-8311691).
Additionally, the product flag
DoReserveCopyInSuperWordcan disable the copy/restore mechanism - and one would hit aShouldNotReachHereinstead. It is unclear why there should be this flag. It was on by default, and until JDK-8311691 it also lead to some bugs (eg. JDK-8308949 where we would crash if the flag was disabled).Argument
I suggest that the flag
DoReserveCopyInSuperWordandCountedLoopReserveKitintroduce complexity for what are essentially very rare edge cases (where we hit asserts, but want to continue somehow in product mode).We should instead chose option 3, and bail out of the compilation (rejecting the inconsistent graph), and retry the compilation without
SuperWord. This increases the work for the edge cases that fail for some reason, but avoids the cloning/copying in all normal cases.CSR
Since
DoReserveCopyInSuperWordis a product flag, we require a CSR to obsolate it: JDK-8317419Testing
Tier1-6 and stress testing (running).
Progress
Issues
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/16022/head:pull/16022$ git checkout pull/16022Update a local copy of the PR:
$ git checkout pull/16022$ git pull https://git.openjdk.org/jdk.git pull/16022/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 16022View PR using the GUI difftool:
$ git pr show -t 16022Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/16022.diff
Webrev
Link to Webrev Comment