-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
8290169: adlc: Improve child constraints for vector unary operations #9534
Conversation
As demonstrated in [1], the child constrait generated for *predicated vector unary operation* is the super set of that generated for the *unpredicated* version. As a result, there exists a risk for predicated vector unary operaions to match the unpredicated rules by accident. In this patch, we resolve this issue by generating one extra check "rChild == NULL" ONLY for vector unary operations. In this way, the child constraints for predicated/unpredicated vector unary operations are exclusive now. Following the example in [1], the dfa state generated for AbsVI is shown below. ``` void State::_sub_Op_AbsVI(const Node *n){ if( STATE__VALID_CHILD(_kids[0], VREG) && STATE__VALID_CHILD(_kids[1], PREGGOV) && ( UseSVE > 0 ) ) { unsigned int c = _kids[0]->_cost[VREG]+_kids[1]->_cost[PREGGOV] + SVE_COST; DFA_PRODUCTION(VREG, vabsI_masked_rule, c) } if( STATE__VALID_CHILD(_kids[0], VREG) && _kids[1] == NULL && <---- 1 ( UseSVE > 0) ) { unsigned int c = _kids[0]->_cost[VREG] + SVE_COST; if (STATE__NOT_YET_VALID(VREG) || _cost[VREG] > c) { DFA_PRODUCTION(VREG, vabsI_rule, c) } } ... ``` We can see that the constraint at line 1 cannot be matched for predicated AbsVI node now. The main updates are made in adlc/dfa part. Ideally, we should only add the extra check for affected platforms, i.e. AVX-512 and SVE. But we didn't do that because it would be better not to introduce any architecture dependent implementation here. Besides, workarounds in both aarch64_sve.ad and x86.ad are removed. 1) Many "is_predicated_vector()" checks can be removed in aarch64_sve.ad file. 2) Default instruction cost is used for involving rules in x86.ad file. [1]. 50ec9b19
👋 Welcome back haosun! A progress list of the required criteria for merging this PR into |
LGTM. |
Resolve the conflicts.
Can anyone help to take a look at this PR? Thanks in advance. |
Looks reasonable to me but I'm not an expert in that area. @jatin-bhateja, @sviswa7, @iwanowww could you have a look? |
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.
AArch64 part looks good to me. Thanks!
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.
@shqking 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 21 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 (@XiaohongGong, @sviswa7) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
@TobiHartmann Thanks for your comment. As some shared code, i.e. |
Sure, I did already run testing. All passed. |
@TobiHartmann Thanks for your testing. /integrate |
/sponsor |
Going to push as commit eeb625e.
Your commit was automatically rebased without conflicts. |
As demonstrated in [1], the child constrait generated for predicated
vector unary operation is the super set of that generated for the
unpredicated version. As a result, there exists a risk for predicated
vector unary operaions to match the unpredicated rules by accident.
In this patch, we resolve this issue by generating one extra check
"rChild == NULL" ONLY for vector unary operations. In this way, the
child constraints for predicated/unpredicated vector unary operations
are exclusive now.
Following the example in [1], the dfa state generated for AbsVI is shown
below.
We can see that the constraint at line 1 cannot be matched for
predicated AbsVI node now.
The main updates are made in adlc/dfa part. Ideally, we should only
add the extra check for affected platforms, i.e. AVX-512 and SVE. But we
didn't do that because it would be better not to introduce any
architecture dependent implementation here.
Besides, workarounds in both
aarch64_sve.adaarch64_vector.ad and x86.ad are removed. 1)Many "is_predicated_vector()" checks can be removed in
aarch64_sve.adaarch64_vector.adfile. 2) Default instruction cost is used for involving rules in x86.ad
file.
[1]. shqking@50ec9b19[1]. shqking@f7d9621e2
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9534/head:pull/9534
$ git checkout pull/9534
Update a local copy of the PR:
$ git checkout pull/9534
$ git pull https://git.openjdk.org/jdk pull/9534/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 9534
View PR using the GUI difftool:
$ git pr show -t 9534
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9534.diff