8286941: Add mask IR for partial vector operations for ARM SVE #9037

XiaohongGong · 2022-06-06T09:42:02Z

VectorAPI SVE backend supports vector operations whose vector length is smaller than the max vector length that the current hardware can support. We call them partial vector operations. For some partial operations like vector load/store and the reductions, we need to generate a mask based on the real vector length and use it to control the operations to make sure the results are correct.

For example, if the user defines an IntVector with 256-bit species, and runs it on a SVE hardware that supports 512-bit as the max vector size, all the 256-bit int vector operations are partial. And a mask that all the higher lanes than the real vector length are set to 0 is generated for some ops.

Currently the mask is generated in the backend that is together with the code generation for each op in the match rule. This will generate many duplicate instructions for operations that have the same vector type. Besides, the mask generation is loop invariant which could be hoisted outside of the loop.

Here is an example for vector load and add reduction inside a loop:

  ptrue   p0.s, vl8             ; mask generation
  ld1w    {z16.s}, p0/z, [x14]  ; load vector

  ptrue   p0.s, vl8             ; mask generation
  uaddv   d17, p0, z16.s        ; add reduction
  smov    x14, v17.s[0]

As we can see the mask generation code "ptrue" is duplicated. To improve it, this patch generates the mask IR and adds it to the partial vector ops before code generation. The duplicate mask generation instructions can be optimized out by gvn and hoisted outside of the loop.

Note that for masked vector operations, there is no need to generate additional mask even though the vector length is smaller than the max vector register size, as the original higher input mask bits have been cleared out.

Here is the performance gain for the 256-bit vector reductions work on an SVE 512-bit system:

  Benchmark                  size   Gain
  Byte256Vector.ADDLanes     1024   0.999
  Byte256Vector.ANDLanes     1024   1.065
  Byte256Vector.MAXLanes     1024   1.064
  Byte256Vector.MINLanes     1024   1.062
  Byte256Vector.ORLanes      1024   1.072
  Byte256Vector.XORLanes     1024   1.041
  Short256Vector.ADDLanes    1024   1.017
  Short256Vector.ANDLanes    1024   1.044
  Short256Vector.MAXLanes    1024   1.049
  Short256Vector.MINLanes    1024   1.049
  Short256Vector.ORLanes     1024   1.089
  Short256Vector.XORLanes    1024   1.047
  Int256Vector.ADDLanes      1024   1.045
  Int256Vector.ANDLanes      1024   1.078
  Int256Vector.MAXLanes      1024   1.123
  Int256Vector.MINLanes      1024   1.129
  Int256Vector.ORLanes       1024   1.078
  Int256Vector.XORLanes      1024   1.072
  Long256Vector.ADDLanes     1024   1.059
  Long256Vector.ANDLanes     1024   1.101
  Long256Vector.MAXLanes     1024   1.079
  Long256Vector.MINLanes     1024   1.099
  Long256Vector.ORLanes      1024   1.098
  Long256Vector.XORLanes     1024   1.110
  Float256Vector.ADDLanes    1024   1.033
  Float256Vector.MAXLanes    1024   1.156
  Float256Vector.MINLanes    1024   1.151
  Double256Vector.ADDLanes   1024   1.062
  Double256Vector.MAXLanes   1024   1.145
  Double256Vector.MINLanes   1024   1.140

This patch also adds 32-bit variants of SVE whileXX instruction with one more matching rule of VectorMaskGen (ConvI2L src). So after this patch, we save one sxtw instruction for most VectorMaskGen cases, like below:

  sxtw    x14, w14
  whilelo p0.s, xzr, x14  =>  whilelo p0.s, wzr, w14

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8286941: Add mask IR for partial vector operations for ARM SVE

Reviewers

Vladimir Kozlov (@vnkozlov - Reviewer)
Jatin Bhateja (@jatin-bhateja - Committer) ⚠️ Review applies to ba59b76e
Ningsheng Jian (@nsjian - Committer) ⚠️ Review applies to 04a2d827
Nick Gasson (@nick-arm - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9037/head:pull/9037
$ git checkout pull/9037

Update a local copy of the PR:
$ git checkout pull/9037
$ git pull https://git.openjdk.org/jdk pull/9037/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9037

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9037.diff

bridgekeeper · 2022-06-06T09:42:10Z

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

openjdk · 2022-06-06T09:44:19Z

@XiaohongGong The following label will be automatically applied to this pull request:

hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2022-06-06T09:48:07Z

Webrevs

vnkozlov

Changes I significant. I suggest to wait JDK 20 (next week).

XiaohongGong · 2022-06-07T01:20:54Z

Sure. It's fine for me to wait the JDK 20. Thanks a lot for the advice!

vnkozlov · 2022-06-08T01:55:12Z

src/hotspot/share/opto/matcher.cpp

    case Op_FmaVD:
    case Op_FmaVF:
    case Op_MacroLogicV:
-    case Op_LoadVectorMasked:


Why it is removed?

Thanks for looking at this PR! This is removed since we added two combined rules in the aarch64_sve.ad (line-2383) like:

match(Set dst (VectorLoadMask (LoadVectorMasked mem pg)));

Setting Op_LoadVectorMasked as a root in matcher will make such rules not be matched. I'm also curious why this op is added here. Does it have any influence if I remove it? Thanks!

@jatin-bhateja, could you please help to check the influence about removing this? Kindly know your feedback about this. Thanks so much!

It was added specifically for #302
It used for ArrayCopyPartialInlineSize code macroArrayCopy.cpp#L250
Yes, it is strange that it is forced to be in register always. The instruction in x86.ad should be enough to put it into register.

@jatin-bhateja, could you please help to check the influence about removing this? Kindly know your feedback about this. Thanks so much!

I think, this can be modified, GVN based sharing should be sufficient here.

Thanks a lot for looking at this part!

vnkozlov · 2022-06-08T02:04:22Z

src/hotspot/share/opto/vectornode.cpp

+Node* MaskAllNode::Ideal(PhaseGVN* phase, bool can_reshape) {
+  // Transform (MaskAll m1 (VectorMaskGen len)) ==> (VectorMaskGen len)
+  // if the vector length in bytes is lower than the MaxVectorSize.
+  if (is_con_M1(in(1)) && length_in_bytes() < MaxVectorSize) {


Due to #8877 such length check may not correct here.
And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

I think changes in #8877 influences the max vector length in superword? And since MaskAll is used for VectorAPI, the MaxVectorSize is still the right reference? @jatin-bhateja, could you please help to check whether this has any influence on x86 avx-512 system? Thanks so much!

And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Yes, the Op_VectorMaskGen is not generated for MaskAll when its input is a constant. We directly transform the MaskAll to VectorMaskGen here, since they two have the same meanings. Thanks!

And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Yes, the Op_VectorMaskGen is not generated for MaskAll when its input is a constant. We directly transform the MaskAll to VectorMaskGen here, since they two have the same meanings. Thanks!

I'm sorry that my comment in line-1819 is not right which misunderstood you. I will change this later. Thanks!

I prefer to not transform MaskAll to VectorMaskGen now, since there are the match rules using MaskAll m1 both in sve and avx-512. Doing the transformation may influence those rules.

I think changes in #8877 influences the max vector length in superword? And since MaskAll is used for VectorAPI, the MaxVectorSize is still the right reference? @jatin-bhateja, could you please help to check whether this has any influence on x86 avx-512 system? Thanks so much!
All these transforms are guarded and currently enabled only for AARCH64, do not think it will impact AVX512.

And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Yes, the Op_VectorMaskGen is not generated for MaskAll when its input is a constant. We directly transform the MaskAll to VectorMaskGen here, since they two have the same meanings. Thanks!

src/hotspot/share/opto/vectornode.cpp

…omments

XiaohongGong · 2022-06-13T01:49:40Z

Hi @vnkozlov , all your review comments are resolved. Could you please help to take a look at this PR again? Thanks so much!

vnkozlov

Thank you for addressing my comments.
You need review from Jatin and someone familiar with aarch64 code (I did not look on it).

vnkozlov · 2022-06-13T18:09:48Z

src/hotspot/share/opto/matcher.cpp

    case Op_FmaVD:
    case Op_FmaVF:
    case Op_MacroLogicV:
-    case Op_LoadVectorMasked:


It was added specifically for #302
It used for ArrayCopyPartialInlineSize code macroArrayCopy.cpp#L250
Yes, it is strange that it is forced to be in register always. The instruction in x86.ad should be enough to put it into register.

src/hotspot/share/opto/vectornode.cpp

XiaohongGong · 2022-06-14T08:54:01Z

Thank you for addressing my comments. You need review from Jatin and someone familiar with aarch64 code (I did not look on it).

Sure, thanks a lot for the review!

XiaohongGong · 2022-06-14T08:55:47Z

Hi @jatin-bhateja, could you please help to take a look at this PR, especially the changes to the LoadVectorMasked? Any feedback is welcome, thanks!

jatin-bhateja · 2022-06-16T08:40:18Z

src/hotspot/share/opto/vectornode.cpp

+  Node* mask = NULL;
+  // Generate a vector mask for vector operation whose vector length is lower than the
+  // hardware supported max vector length.
+  if (vt->length_in_bytes() < MaxVectorSize) {


For completeness, length comparison check can be done against MIN(SuperWordMaxVectorSize, MaxVectorSize).
Even though SuperWordMaxVector differs from MaxVectorSize only for certain X86 targets and this control flow is only executed for AARCH64 SVE targets currently.

Yes, I agree with you to add the SuperWordMaxVectorSize reference. Thanks! I will change it.

I'm afraid that we cannot directly use MIN(SuperWordMaxVectorSize, MaxVectorSize) here. As I know SuperWordMaxVectorSize is used to control the max vector limit specially for auto-vectorization. It should not have any influence to the VectorAPI max vector size. So if the supported max vector size for VetorAPI is larger than auto-vectorization, the transformation will be influenced. For example, if a SVE hardware supported 128-bytes max vector size, but the SuperWordMaxVectorSize is 64, the predicate will not be generated for vectors whose vector size is smaller than 128-bytes. And I think x86 also has the similar issue. I think we'd better need a unit method to compute the max_vector_size that can handle the differences for superword and VectorAPI. And then all the orignal max_vector_size should be replaced with it. WDYT?

BTW, the max vector size used here should be referenced from the hardware supported max vector size, which should be MaxVectorSize for SVE. For those vectors whose vector size is SuperWordMaxVectorSize, but smaller than the hardware supported max size, we still need to generate a predicate for them to make sure the results are right. So using MaxVectorSize is necessary here.

The mask is generated based on the real vector length, which guarantees only the vector lanes that inside of its valid vector length will do the operations. Higher lanes do nothing. So if a VectorStore has a vector length which equals to SuperWordMaxVectorSize, but the MaxVectorSize is larger than the SuperWordMaxVectorSize, a mask will be generated based on the real length SuperWordMaxVectorSize. And only lanes under the SuperWordMaxVectorSize will be stored. So I cannot see the influence on the out of memory issue. Could you please give an example apart of x86 cases? Thanks so much!

BTW, I think flag SuperWordMaxVectorSize should be equal to MaxVectorSize by default for other platforms instead of 64. If a platform (liken SVE) supports >64 bytes max vector size for auto-vectorization, it can only generate the vectors with 64 bytes vector size. This seems unreasonable. So do you have any plan refactoring this flag, or removing the usages for it in future? Thanks!

The mask is generated based on the real vector length, which guarantees only the vector lanes that inside of its valid vector length will do the operations. Higher lanes do nothing. So if a VectorStore has a vector length which equals to SuperWordMaxVectorSize, but the MaxVectorSize is larger than the SuperWordMaxVectorSize, a mask will be generated based on the real length SuperWordMaxVectorSize. And only lanes under the SuperWordMaxVectorSize will be stored. So I cannot see the influence on the out of memory issue. Could you please give an example apart of x86 cases? Thanks so much!

Correct, got it, removed my above review comment.

BTW, I think flag SuperWordMaxVectorSize should be equal to MaxVectorSize by default for other platforms instead of 64. If a platform (liken SVE) supports >64 bytes max vector size for auto-vectorization, it can only generate the vectors with 64 bytes vector size. This seems unreasonable. So do you have any plan refactoring this flag, or removing the usages for it in future? Thanks!

jatin-bhateja · 2022-06-16T09:12:09Z

src/hotspot/share/opto/vectornode.cpp

    }
  }
-  return NULL;
+  return LoadVectorNode::Ideal(phase, can_reshape);


These predicated nodes are concrete ones with fixed species and carry user specified mask, I am not clear why do we need a mask re-computation for predicated nodes.

Higher lanes of predicated operand should already be zero and mask attached to predicated node should be correct by construction, since mask lane count is always equal to vector lane count.

Actually we don't need to add an additional mask for these masked nodes for SVE. Please refer to the partial_op_sve_needed method in aarch64_sve.ad, which lists all the ops that needs this transformation. Thanks! LoadVectorNode::Ideal(phase, can_reshape) just because LoadVectorMaskedNode derived from LoadVectorNode, that it may derive its other transformations in future or for other platforms.

jatin-bhateja · 2022-06-16T09:12:48Z

src/hotspot/share/opto/vectornode.cpp

    }
  }
-  return NULL;
+  return StoreVectorNode::Ideal(phase, can_reshape);


Same as above.

Same as LoadVectorMaskedNode, StoreVectorMaskedNode doesn't need the transformation as well.

jatin-bhateja · 2022-06-16T09:34:17Z

src/hotspot/share/opto/matcher.cpp

    case Op_FmaVD:
    case Op_FmaVF:
    case Op_MacroLogicV:
-    case Op_LoadVectorMasked:


@jatin-bhateja, could you please help to check the influence about removing this? Kindly know your feedback about this. Thanks so much!

I think, this can be modified, GVN based sharing should be sufficient here.

jatin-bhateja · 2022-06-16T09:54:17Z

src/hotspot/share/opto/vectornode.cpp

+  if (Matcher::vector_needs_partial_operations(this, vt)) {
+    return VectorNode::try_to_gen_masked_vector(phase, this, vt);
+  }


This is a parent node of TrueCount/FirstTrue/LastTrue and MaskToLong which perform mask querying operation on concrete predicate operands, a transformation here looks redundant to me.

The main reason to add the transformation here is: the FirstTrue needs the reference to the real vector length for SVE, that we need to generate a predicate when the vector length is smaller than the max vector size. Please check the changes of partial_op_sve_needed in aarch64_sve.ad.

Real vector length can be obtained by incoming input mask node.

jatin-bhateja · 2022-06-16T12:21:17Z

src/hotspot/share/opto/vectornode.cpp

+Node* MaskAllNode::Ideal(PhaseGVN* phase, bool can_reshape) {
+  // Transform (MaskAll m1 (VectorMaskGen len)) ==> (VectorMaskGen len)
+  // if the vector length in bytes is lower than the MaxVectorSize.
+  if (is_con_M1(in(1)) && length_in_bytes() < MaxVectorSize) {


I think changes in #8877 influences the max vector length in superword? And since MaskAll is used for VectorAPI, the MaxVectorSize is still the right reference? @jatin-bhateja, could you please help to check whether this has any influence on x86 avx-512 system? Thanks so much!
All these transforms are guarded and currently enabled only for AARCH64, do not think it will impact AVX512.

And I don't see in(2)->Opcode() == Op_VectorMaskGen check.

Yes, the Op_VectorMaskGen is not generated for MaskAll when its input is a constant. We directly transform the MaskAll to VectorMaskGen here, since they two have the same meanings. Thanks!

jatin-bhateja

Hi @XiaohongGong , thanks for your explanations, common IR changes looks good to me.

jatin-bhateja · 2022-06-20T13:12:24Z

src/hotspot/share/opto/vectornode.cpp

+  if (Matcher::vector_needs_partial_operations(this, vt)) {
+    return VectorNode::try_to_gen_masked_vector(phase, this, vt);
+  }


Real vector length can be obtained by incoming input mask node.

src/hotspot/cpu/aarch64/assembler_aarch64.hpp

nsjian

AArch64 changes look good to me.

XiaohongGong · 2022-06-29T06:19:27Z

AArch64 changes look good to me.

Thanks for the review @nsjian !

vnkozlov · 2022-06-30T02:11:56Z

I submitted testing. Will let you know results before approval.

XiaohongGong · 2022-06-30T02:13:07Z

I submitted testing. Will let you know results before approval.

Thanks a lot for doing this!

vnkozlov · 2022-06-30T02:46:56Z

I got failure in tier1:

test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp:48: Failure
Expected equality of these values:
  insns[i]
    Which is: 624694305
  insns1[i]
    Which is: 624690209
Ours:
[MachCode]
  0x0000fffca812c698: 2104 3c25 
[/MachCode]
Theirs:
[MachCode]
  0x0000fffc9599d188: 2114 3c25 
[/MachCode]

vnkozlov · 2022-06-30T02:59:26Z

I put output into RFE comment.

XiaohongGong · 2022-06-30T03:06:21Z

I got failure in tier1:

test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp:48: Failure
Expected equality of these values:
  insns[i]
    Which is: 624694305
  insns1[i]
    Which is: 624690209
Ours:
[MachCode]
  0x0000fffca812c698: 2104 3c25 
[/MachCode]
Theirs:
[MachCode]
  0x0000fffc9599d188: 2114 3c25 
[/MachCode]

Thanks for pointing out this! My fault. I called wrong assembler function in the new added tests. I will fix it soon!

XiaohongGong · 2022-06-30T07:06:53Z

Hi @vnkozlov , the fix is pushed to this PR. Would you mind running the test again? Thanks so much!

XiaohongGong · 2022-06-30T07:24:46Z

Hi @nick-arm , could you please help to take a look at the aarch64 part changes? Thanks so much for your time!

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp

vnkozlov · 2022-06-30T17:51:34Z

An other test failed in tier2: compiler/loopopts/superword/TestPickFirstMemoryState.java
Details are in RFE.

XiaohongGong · 2022-07-01T02:39:32Z

An other test failed in tier2: compiler/loopopts/superword/TestPickFirstMemoryState.java Details are in RFE.

Thanks for the tests again! It seems this is the same issue with #2867 that the type of in(2) is Type::TOP. We need to add save the vector type for ReductionNode. I will fix it soon!

XiaohongGong · 2022-07-04T10:14:36Z

Hi @vnkozlov , the fixing is pushed to the PR. I tested the failure case on a avx-512 machine, and the failure gone. Could you please help to run the test again? Thanks a lot!

vnkozlov · 2022-07-05T18:21:53Z

I started new testing.

vnkozlov

Results are good.

openjdk · 2022-07-06T05:56:08Z

@XiaohongGong 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:

8286941: Add mask IR for partial vector operations for ARM SVE

Reviewed-by: kvn, jbhateja, njian, ngasson

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 207 new commits pushed to the master branch:

569de45: 8289620: gtest/MetaspaceUtilsGtests.java failed with unexpected stats values
403a9bc: 8289436: Make the redefine timer statistics more accurate
a40c17b: 8289775: Update java.lang.invoke.MethodHandle[s] to use snippets
2a6ec88: Merge
0526402: 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc
b3a0e48: 8289439: Clarify relationship between ThreadStart/ThreadEnd and can_support_virtual_threads capability
0b6fd48: 8288128: S390X: Fix crashes after JDK-8284161 (Virtual Threads)
30e134e: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj()
29ea642: 8287847: Fatal Error when suspending virtual thread after it has terminated
f640fc5: 8067757: Incorrect HTML generation for copied javadoc with multiple @throws tags
... and 197 more: https://git.openjdk.org/jdk/compare/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e...master

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 master branch, type /integrate in a new comment.

XiaohongGong · 2022-07-06T06:00:52Z

Results are good.

Thanks a lot for your time again!

XiaohongGong · 2022-07-07T06:09:29Z

@nick-arm , could you please take a look at this change again? Thanks so much!

XiaohongGong · 2022-07-07T08:06:04Z

Thanks for the reivew @nick-arm !

XiaohongGong · 2022-07-07T08:12:42Z

/integrate

openjdk · 2022-07-07T08:14:36Z

Going to push as commit a79ce4e.
Since your change was applied there have been 207 commits pushed to the master branch:

569de45: 8289620: gtest/MetaspaceUtilsGtests.java failed with unexpected stats values
403a9bc: 8289436: Make the redefine timer statistics more accurate
a40c17b: 8289775: Update java.lang.invoke.MethodHandle[s] to use snippets
2a6ec88: Merge
0526402: 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc
b3a0e48: 8289439: Clarify relationship between ThreadStart/ThreadEnd and can_support_virtual_threads capability
0b6fd48: 8288128: S390X: Fix crashes after JDK-8284161 (Virtual Threads)
30e134e: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj()
29ea642: 8287847: Fatal Error when suspending virtual thread after it has terminated
f640fc5: 8067757: Incorrect HTML generation for copied javadoc with multiple @throws tags
... and 197 more: https://git.openjdk.org/jdk/compare/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-07-07T08:15:06Z

@XiaohongGong Pushed as commit a79ce4e.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8286941: Add mask IR for partial vector operations for ARM SVE

008a2a1

openjdk bot added the rfr Pull request is ready for review label Jun 6, 2022

openjdk bot added the hotspot-compiler [email protected] label Jun 6, 2022

vnkozlov reviewed Jun 6, 2022

View reviewed changes

vnkozlov reviewed Jun 8, 2022

View reviewed changes

Revert transformation from MaskAll to VectorMaskGen, address review c…

c71db59

…omments

vnkozlov reviewed Jun 13, 2022

View reviewed changes

Xiaohong Gong added 2 commits June 14, 2022 08:50

Merge branch 'jdk:master' into JDK-8286941

c9ca812

Address review comments, revert changes for gatherL/scatterL rules

fc11338

jatin-bhateja reviewed Jun 16, 2022

View reviewed changes

Fix the ci build issue

ba59b76

jatin-bhateja approved these changes Jun 20, 2022

View reviewed changes

Merge branch 'jdk:master' into JDK-8286941

caf5eb0

nsjian reviewed Jun 28, 2022

View reviewed changes

src/hotspot/cpu/aarch64/assembler_aarch64.hpp Outdated Show resolved Hide resolved

Address review comments

04a2d82

nsjian approved these changes Jun 29, 2022

View reviewed changes

Fix assembler test issue

061a19f

nick-arm reviewed Jun 30, 2022

View reviewed changes

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp Outdated Show resolved Hide resolved

Address review comments

8bda781

Save vect_type to ReductionNode and VectorMaskOpNode

cafca90

vnkozlov approved these changes Jul 6, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jul 6, 2022

nick-arm approved these changes Jul 7, 2022

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Jul 7, 2022

openjdk bot closed this Jul 7, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jul 7, 2022

XiaohongGong deleted the JDK-8286941 branch July 7, 2022 08:16

8286941: Add mask IR for partial vector operations for ARM SVE #9037

8286941: Add mask IR for partial vector operations for ARM SVE #9037

Uh oh!

Conversation

XiaohongGong commented Jun 6, 2022 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Jun 6, 2022

Uh oh!

openjdk bot commented Jun 6, 2022

Uh oh!

mlbridge bot commented Jun 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

vnkozlov left a comment

Choose a reason for hiding this comment

Uh oh!

XiaohongGong commented Jun 7, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

XiaohongGong commented Jun 13, 2022

Uh oh!

vnkozlov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

XiaohongGong commented Jun 14, 2022

Uh oh!

XiaohongGong commented Jun 14, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

XiaohongGong Jun 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jatin-bhateja Jun 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

XiaohongGong commented Jun 6, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Jun 6, 2022 •

edited

Loading

XiaohongGong Jun 20, 2022 •

edited

Loading

jatin-bhateja Jun 20, 2022 •

edited

Loading