8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota #81

Wanghuang-Huawei · 2021-05-12T09:20:47Z

Because JDK-8266317 has not been merged into jdk/jdk. So I fix this bug here.

This comparsion should be a unsigned cmp
x86 is not wrong because x86 does not have 1024-bits vl here.

  ConINode* pred_node = (ConINode*)gvn().makecon(TypeInt::make(BoolTest::ge)); // should BoolTest::ugt
  Node * lane_cnt  = gvn().makecon(TypeInt::make(num_elem));
  Node * bcast_lane_cnt = gvn().transform(VectorNode::scalar2vector(lane_cnt, num_elem, type_bt));
  // should BoolTest::ugt
  Node* mask = gvn().transform(new VectorMaskCmpNode(BoolTest::ge, bcast_lane_cnt, res, pred_node, vt));

Progress

Change must not contain extraneous whitespace
Change must be properly reviewed (1 review required, with at least 1 Committer)

Error

⚠️ Executable files are not allowed (file: src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh)

Integration blockers

⚠️ Executable files are not allowed (file: src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh) (failed with the updated jcheck configuration)
⚠️ Whitespace errors (failed with the updated jcheck configuration)

Issue

JDK-8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota (Bug - P2)

Contributors

Wang Huang <whuang@openjdk.org>
Ai Jiaming <aijiaming1@huawei.com>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/panama-vector.git pull/81/head:pull/81
$ git checkout pull/81

Update a local copy of the PR:
$ git checkout pull/81
$ git pull https://git.openjdk.org/panama-vector.git pull/81/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 81

View PR using the GUI difftool:
$ git pr show -t 81

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/panama-vector/pull/81.diff

Webrev

Link to Webrev Comment

…e_iota

bridgekeeper · 2021-05-12T09:21:10Z

👋 Welcome back whuang! A progress list of the required criteria for merging this PR into vectorIntrinsics will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

Wanghuang-Huawei · 2021-05-12T09:21:29Z

/contributor add Wang Huang whuang@openjdk.org
/contributor add Ai Jiaming aijiaming1@huawei.com

openjdk · 2021-05-12T09:22:51Z

@Wanghuang-Huawei
Contributor Wang Huang <whuang@openjdk.org> successfully added.

openjdk · 2021-05-12T09:25:20Z

@Wanghuang-Huawei
Contributor Ai Jiaming <aijiaming1@huawei.com> successfully added.

mlbridge · 2021-05-12T09:37:30Z

Webrevs

PaulSandoz · 2021-05-12T15:17:45Z

test/hotspot/jtreg/compiler/vectorapi/TestVectorShuffleIota1024.java

+ * @test
+ * @bug 8266720
+ * @modules jdk.incubator.vector
+ * @run testng/othervm compiler.vectorapi.TestVectorShuffleIotaByte1024


Perhaps the test can be annotated, declaring it should only execute on ARM/SVE platforms. See the use of the @requires clause used in other JDK tests.

Thank you for you review. I think this test is used for any arch which has ByteVector.SPECIES_MAX == 1024.

But we know which arches don't support, x86, PPC etc.

I am unsure why existing shuffle tests do not catch this problem. In fact i would prefer we focus on that if we can rather than adding a specific test. Would you mind looking to see if see if we can expand on the existing shuffleTest?

Q : Why existing shuffle tests do not catch this problem?

A: Because we need vector_length >= 1024. However, in x86 we don't have this env because the longest register of x86 is 512 in AVX512.

sviswa7 · 2021-05-13T17:57:20Z

src/hotspot/share/opto/vectorIntrinsics.cpp

@@ -453,10 +453,10 @@ bool LibraryCallKit::inline_vector_shuffle_iota() {
    // Wrap the indices greater than lane count.
    res = gvn().transform(VectorNode::make(Op_AndI, res, bcast_mod, num_elem, elem_bt));
  } else {
-    ConINode* pred_node = (ConINode*)gvn().makecon(TypeInt::make(BoolTest::ge));
+    ConINode* pred_node = (ConINode*)gvn().makecon(TypeInt::make(BoolTest::ugt));


Unsigned comparison adds overhead and is not supported on all architectures.

After changing notes with @XiaohongGong , I think we can also fix like this:

ConINode* pred_node = (ConINode*)gvn().makecon(TypeInt::make(BoolTest::ge)); Node * lane_cnt_tmp = gvn().makecon(TypeInt::make(num_elem - 1)); Node * bcast_lane_cnt_tmp = gvn().transform(VectorNode::scalar2vector(lane_cnt_tmp, num_elem, type_bt)); Node* mask = gvn().transform(new VectorMaskCmpNode(BoolTest::ge, bcast_lane_cnt_tmp, res, pred_node, vt)); // Make the indices greater than lane count as -ve values. This matches the java side implementation. res = gvn().transform(VectorNode::make(Op_AndI, res, bcast_mod, num_elem, elem_bt)); Node * lane_cnt = gvn().makecon(TypeInt::make(num_elem)); // Add a mov & bcast here Node * bcast_lane_cnt = gvn().transform(VectorNode::scalar2vector(lane_cnt, num_elem, type_bt)); Node * biased_val = gvn().transform(VectorNode::make(Op_SubI, res, bcast_lane_cnt, num_elem, elem_bt)); res = gvn().transform(new VectorBlendNode(biased_val, res, mask));

Unsigned comparison adds overhead and is not supported on all architectures.

However, if we don't use ugt ,we will encounter problem if length > 1024 in future. Changing < num_elem to <= 128 is just a solution to 1024 itself. If num_elem > 128, it will be invalid.

Currently making it work well for <= 1024-bits makes sense to me. We can revisit this issue after the API issues for vector length > 1024-bits are fixed in future.

Currently making it work well for <= 1024-bits makes sense to me. We can revisit this issue after the API issues for vector length > 1024-bits are fixed in future.

If so, we need at least some comments or even length check to not inline for unsupported vector lengths?

Agree with @nsjian ! Thanks!

If we use ge 1024 , we will add two more nodes. It is a extra cost here?

XiaohongGong · 2021-06-03T03:13:39Z

src/hotspot/share/opto/vectorIntrinsics.cpp

+      // Currently it works well for vector_length <= 1024-bits.
+      // for vector_length > 1024, we don't support now


Does it need any vector length check or block for vector length >1024?

Thank you for your review. It is a problem here. I will do that in next commit.

As discussed with @nsjian , can we currently make it unsupported as well for 1024-bits? It doesn't need to change any IR if 1024-bits is not supported. We can revisit this issue in future for vector length >= 1024-bits

openjdk · 2023-02-17T18:34:41Z

@Wanghuang-Huawei this pull request can not be integrated into vectorIntrinsics due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8266720
git fetch https://git.openjdk.org/panama-vector vectorIntrinsics
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge vectorIntrinsics"
git push

8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffl…

ba8b5e0

…e_iota

fix format

ab1e3c1

openjdk bot added the rfr label May 12, 2021

PaulSandoz reviewed May 12, 2021

View reviewed changes

sviswa7 reviewed May 13, 2021

View reviewed changes

Wanghuang-Huawei added 2 commits June 2, 2021 11:08

merge vectorIntrinsics

781d67c

only fix IR

bd17e1d

XiaohongGong reviewed Jun 3, 2021

View reviewed changes

openjdk bot added merge-conflict and removed rfr labels Feb 17, 2023

8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota #81

8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota #81

Wanghuang-Huawei commented May 12, 2021 •

edited by openjdk bot

bridgekeeper bot commented May 12, 2021

Wanghuang-Huawei commented May 12, 2021

openjdk bot commented May 12, 2021

openjdk bot commented May 12, 2021

mlbridge bot commented May 12, 2021 •

edited

PaulSandoz May 12, 2021

Wanghuang-Huawei May 13, 2021

PaulSandoz May 13, 2021

Wanghuang-Huawei Jun 4, 2021

sviswa7 May 13, 2021

Wanghuang-Huawei May 14, 2021 •

edited

Wanghuang-Huawei May 14, 2021 •

edited

XiaohongGong May 14, 2021

nsjian May 14, 2021 •

edited

XiaohongGong May 14, 2021

Wanghuang-Huawei May 17, 2021

XiaohongGong Jun 3, 2021

Wanghuang-Huawei Jun 3, 2021 •

edited

XiaohongGong Jun 4, 2021

openjdk bot commented Feb 17, 2023

		// Currently it works well for vector_length <= 1024-bits.
		// for vector_length > 1024, we don't support now

8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota #81

Are you sure you want to change the base?

8266720: Wrong implementation in LibraryCallKit::inline_vector_shuffle_iota #81

Conversation

Wanghuang-Huawei commented May 12, 2021 • edited by openjdk bot

Progress

Error

Integration blockers

Issue

Contributors

Reviewing

Webrev

bridgekeeper bot commented May 12, 2021

Wanghuang-Huawei commented May 12, 2021

openjdk bot commented May 12, 2021

openjdk bot commented May 12, 2021

mlbridge bot commented May 12, 2021 • edited

Webrevs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Wanghuang-Huawei May 14, 2021 • edited

Choose a reason for hiding this comment

Wanghuang-Huawei May 14, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nsjian May 14, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Wanghuang-Huawei Jun 3, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openjdk bot commented Feb 17, 2023

Wanghuang-Huawei commented May 12, 2021 •

edited by openjdk bot

mlbridge bot commented May 12, 2021 •

edited

Wanghuang-Huawei May 14, 2021 •

edited

Wanghuang-Huawei May 14, 2021 •

edited

nsjian May 14, 2021 •

edited

Wanghuang-Huawei Jun 3, 2021 •

edited