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
8265321: Add Rearrange nodes implementation for Arm SVE #70
8265321: Add Rearrange nodes implementation for Arm SVE #70
Conversation
👋 Welcome back whuang! A progress list of the required criteria for merging this PR into |
/contributor add Wang Huang whuang@openjdk.org |
@Wanghuang-Huawei |
@Wanghuang-Huawei |
Webrevs
|
instruct rearrangeL(vReg dst, vReg src, vReg shuffle) | ||
%{ | ||
predicate(UseSVE > 0 && | ||
n->bottom_type()->is_vect()->element_basic_type() == T_LONG); | ||
match(Set dst (VectorRearrange src shuffle)); | ||
ins_cost(SVE_COST); | ||
format %{ "sve_tbl $dst, D, $src, $shuffle\t# vector rearrange (D)" %} | ||
ins_encode %{ | ||
__ sve_tbl(as_FloatRegister($dst$$reg), __ D, | ||
as_FloatRegister($src$$reg), as_FloatRegister($shuffle$$reg)); | ||
%} | ||
ins_pipe(pipe_slow); | ||
%} | ||
|
||
instruct rearrangeD(vReg dst, vReg src, vReg shuffle) | ||
%{ | ||
predicate(UseSVE > 0 && | ||
n->bottom_type()->is_vect()->element_basic_type() == T_DOUBLE); | ||
match(Set dst (VectorRearrange src shuffle)); | ||
ins_cost(SVE_COST); | ||
format %{ "sve_tbl $dst, D, $src, $shuffle\t# vector rearrange (D)" %} | ||
ins_encode %{ | ||
__ sve_tbl(as_FloatRegister($dst$$reg), __ D, | ||
as_FloatRegister($src$$reg), as_FloatRegister($shuffle$$reg)); | ||
%} | ||
ins_pipe(pipe_slow); | ||
%} |
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.
At least merge long/double
and float/int
? The format looks the same.
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 think it's my fault. The comment is L
for rearrangeL
instead of D
. I will fix it in my next patch.
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 also prefer merging them instead of having two separate rules. From the instruction point of view, there's only D, not L.
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 also prefer merging them instead of having two separate rules. From the instruction point of view, there's only D, not L.
Thank you for your review.
- I think that the comment is the node's comment (or rule's comment) instead of single instruction's comment. This rule is
rearrangeL
which means rearranging long type so I think that the comment should beL
instead ofD
. - In
aarch64_neon.ad
, the comments areB``I``F``D
and so on.
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 think that the comment is the node's comment (or rule's comment) instead of single instruction's comment. This rule is
rearrangeL
which means rearranging long type so I think that the comment should beL
instead ofD
.- In
aarch64_neon.ad
, the comments areB
IF
D `` and so on.
I assume you mean comment in format section. In aarch64_neon, some are S while some are F, but I don't think there's a need to generate two rules just for different format comments. If there's any, I would suggest to fix them as well.
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 think that the comment is the node's comment (or rule's comment) instead of single instruction's comment. This rule is
rearrangeL
which means rearranging long type so I think that the comment should beL
instead ofD
.- In
aarch64_neon.ad
, the comments areB
IF
D `` and so on.I assume you mean comment in format section. In aarch64_neon, some are S while some are F, but I don't think there's a need to generate two rules just for different format comments. If there's any, I would suggest to fix them as well.
Of course, in some case L
and D
can be zipped in one rule. However, in some case, L
and D
is difference. D
is float type. That is what I mentioned before the comment is for the whole rule
. In the comment, we should show the data type. ;-)
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.
Some cases are different, but I don't think we need to distinguish floating point data types for this operation as they are actually the same thing and generate the same code.
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.
Agree with @nsjian . I prefer to merge all these rules into one as we have discussed too much times before, as there is no instruction difference for different types. Anyway, we can have a separate patch to unify the styles in ad file.
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.
Some cases are different, but I don't think we need to distinguish floating point data types for this operation as they are actually the same thing and generate the same code.
Yes, I think for this rule L
and D
have the same form. However, the comment itself should be consistent with others. In other case, we should distinguish floating point data types. That is why I choose to use L
instead of D
.
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 really want to have a correct comment, you can comment as something like "(L/D)" - though I doubt if it really make any sense for your testing/debugging.
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.
Thanks for the work! Overall looks good to me. Just some nits.
switch (opcode) { | ||
case Op_VectorLoadShuffle: | ||
case Op_VectorRearrange: | ||
if (vlen < 4) { | ||
return false; | ||
} | ||
break; | ||
default: | ||
break; | ||
} |
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 would prefer put this inside op_sve_supported.
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, I will fix that.
@@ -4057,7 +4057,7 @@ instruct rearrangeL(vReg dst, vReg src, vReg shuffle) | |||
n->bottom_type()->is_vect()->element_basic_type() == T_LONG); | |||
match(Set dst (VectorRearrange src shuffle)); | |||
ins_cost(SVE_COST); | |||
format %{ "sve_tbl $dst, D, $src, $shuffle\t# vector rearrange (D)" %} | |||
format %{ "sve_tbl $dst, D, $src, $shuffle\t# vector rearrange (L)" %} |
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 still think that it make no sense to separate these rules. But anyway, I can do a cleanup later. FYI: Xiaohong and our Intel friends are working hard trying not to increase the instruction selection patterns on masking support design: http://openjdk.java.net/jeps/8261663.
@Wanghuang-Huawei 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 1 new commit pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
@Wanghuang-Huawei Since your change was applied there has been 1 commit pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 6d5c8bd. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
sve_tbl
, which reads each element of the second source (index) vector and uses its value to select an indexed element from the first source (table) vector, and places the indexed table element in the destination vector element corresponding to the index vector element. If an index value is greater than or equal to the number of vector elements then it places zero in the corresponding destination vector element.[1][1] https://developer.arm.com/documentation/ddi0596/2020-12/SVE-Instructions/TBL--Programmable-table-lookup-in-single-vector-table-?lang=en
Progress
Issue
Reviewers
Contributors
<whuang@openjdk.org>
<aijiaming1@huawei.com>
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/panama-vector pull/70/head:pull/70
$ git checkout pull/70
Update a local copy of the PR:
$ git checkout pull/70
$ git pull https://git.openjdk.java.net/panama-vector pull/70/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 70
View PR using the GUI difftool:
$ git pr show -t 70
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/panama-vector/pull/70.diff