8322770: Implement C2 VectorizedHashCode on AArch64 #18487

mikabl-arm · 2024-03-26T13:59:12Z

Hello,

Please review the following PR for JDK-8322770 Implement C2 VectorizedHashCode on AArch64. It follows previous work done in #16629 and #10847 for RISC-V and x86 respectively.

The code to calculate a hash code consists of two parts: a vectorized loop of Neon instruction that process 4 or 8 elements per iteration depending on the data type and a fully unrolled scalar "loop" that processes up to 7 tail elements.

At the time of writing this I don't see potential benefits from providing SVE/SVE2 implementation, but it could be added as a follow-up or independently later if required.

Performance

Neoverse N1

  --------------------------------------------------------------------------------------------
  Version                                            Baseline           This patch
  --------------------------------------------------------------------------------------------
  Benchmark                   (size)  Mode  Cnt      Score    Error     Score     Error  Units
  --------------------------------------------------------------------------------------------
  ArraysHashCode.bytes             1  avgt   15      1.249 ?  0.060     1.247 ?   0.062  ns/op
  ArraysHashCode.bytes            10  avgt   15      8.754 ?  0.028     4.387 ?   0.015  ns/op
  ArraysHashCode.bytes           100  avgt   15     98.596 ?  0.051    26.655 ?   0.097  ns/op
  ArraysHashCode.bytes         10000  avgt   15  10150.578 ?  1.352  2649.962 ? 216.744  ns/op
  ArraysHashCode.chars             1  avgt   15      1.286 ?  0.062     1.246 ?   0.054  ns/op
  ArraysHashCode.chars            10  avgt   15      8.731 ?  0.002     5.344 ?   0.003  ns/op
  ArraysHashCode.chars           100  avgt   15     98.632 ?  0.048    23.023 ?   0.142  ns/op
  ArraysHashCode.chars         10000  avgt   15  10150.658 ?  3.374  2410.504 ?   8.872  ns/op
  ArraysHashCode.ints              1  avgt   15      1.189 ?  0.005     1.187 ?   0.001  ns/op
  ArraysHashCode.ints             10  avgt   15      8.730 ?  0.002     5.676 ?   0.001  ns/op
  ArraysHashCode.ints            100  avgt   15     98.559 ?  0.016    24.378 ?   0.006  ns/op
  ArraysHashCode.ints          10000  avgt   15  10148.752 ?  1.336  2419.015 ?   0.492  ns/op
  ArraysHashCode.multibytes        1  avgt   15      1.037 ?  0.001     1.037 ?   0.001  ns/op
  ArraysHashCode.multibytes       10  avgt   15      5.481 ?  0.001     3.136 ?   0.001  ns/op
  ArraysHashCode.multibytes      100  avgt   15     50.950 ?  0.006    15.277 ?   0.007  ns/op
  ArraysHashCode.multibytes    10000  avgt   15   5335.181 ?  0.692  1340.850 ?   4.291  ns/op
  ArraysHashCode.multichars        1  avgt   15      1.038 ?  0.001     1.037 ?   0.001  ns/op
  ArraysHashCode.multichars       10  avgt   15      5.480 ?  0.001     3.783 ?   0.001  ns/op
  ArraysHashCode.multichars      100  avgt   15     50.955 ?  0.006    13.890 ?   0.018  ns/op
  ArraysHashCode.multichars    10000  avgt   15   5338.597 ?  0.853  1335.599 ?   0.652  ns/op
  ArraysHashCode.multiints         1  avgt   15      1.042 ?  0.001     1.043 ?   0.001  ns/op
  ArraysHashCode.multiints        10  avgt   15      5.526 ?  0.001     3.866 ?   0.001  ns/op
  ArraysHashCode.multiints       100  avgt   15     50.917 ?  0.005    14.918 ?   0.026  ns/op
  ArraysHashCode.multiints     10000  avgt   15   5348.365 ?  5.836  1287.685 ?   1.083  ns/op
  ArraysHashCode.multishorts       1  avgt   15      1.036 ?  0.001     1.037 ?   0.001  ns/op
  ArraysHashCode.multishorts      10  avgt   15      5.480 ?  0.001     3.783 ?   0.001  ns/op
  ArraysHashCode.multishorts     100  avgt   15     50.975 ?  0.034    13.890 ?   0.015  ns/op
  ArraysHashCode.multishorts   10000  avgt   15   5338.790 ?  1.276  1337.034 ?   1.600  ns/op
  ArraysHashCode.shorts            1  avgt   15      1.187 ?  0.001     1.187 ?   0.001  ns/op
  ArraysHashCode.shorts           10  avgt   15      8.731 ?  0.002     5.342 ?   0.001  ns/op
  ArraysHashCode.shorts          100  avgt   15     98.544 ?  0.013    23.017 ?   0.141  ns/op
  ArraysHashCode.shorts        10000  avgt   15  10148.275 ?  1.119  2408.041 ?   1.478  ns/op

Neoverse N2, Neoverse V1

Performance metrics have been collected for these cores as well. They are similar to the results above and can be posted upon request.

Test

Full jtreg passed on AArch64 and x86.

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-8322770: Implement C2 VectorizedHashCode on AArch64 (Enhancement - P4)

Reviewers

Andrew Haley (@theRealAph - Reviewer)
Andrew Dinn (@adinn - Reviewer) Review applies to 142fa5d0

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18487

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

Using diff file

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

Webrev

Link to Webrev Comment

bridgekeeper · 2024-03-26T13:59:45Z

Hi @mikabl-arm, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user mikabl-arm" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

openjdk · 2024-03-26T14:00:00Z

@mikabl-arm 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:

8322770: Implement C2 VectorizedHashCode on AArch64

Reviewed-by: aph, adinn

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

52ba728: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
988a531: 8340181: Shenandoah: Cleanup ShenandoahRuntime stubs
822a773: 8340605: Open source several AWT PopupMenu tests
6514aef: 8340419: ZGC: Create an UseLargePages adaptation of TestAllocateHeapAt.java
ae4d2f1: 8340621: Open source several AWT List tests
dd56990: 8340639: Open source few more AWT List tests
ade17ec: 8340560: Open Source several AWT/2D font and rendering tests
73ebb84: 8340721: Clarify special case handling of unboxedType and getWildcardType
ed140f5: 8341101: [ARM32] Error: ShouldNotReachHere() in TemplateInterpreterGenerator::generate_math_entry after 8338694
082125d: 8340404: CharsetProvider specification updates
... and 155 more: https://git.openjdk.org/jdk/compare/4ff17c14a572a59b60d728c3626f430932eecea6...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.

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 (@theRealAph, @adinn) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

openjdk · 2024-03-26T14:00:31Z

@mikabl-arm The following label will be automatically applied to this pull request:

hotspot

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.

mikabl-arm · 2024-03-26T14:09:44Z

/covered

bridgekeeper · 2024-03-26T14:10:10Z

Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

dchuyko · 2024-03-28T11:20:47Z

Just a trivial note: this change also improves the calculation of String.hashCode(). For instance, on V1

Benchmark	size	Improvement
StringHashCode.Algorithm.defaultLatin1	1	-2.86%
StringHashCode.Algorithm.defaultLatin1	10	45.84%
StringHashCode.Algorithm.defaultLatin1	100	79.43%
StringHashCode.Algorithm.defaultLatin1	10000	79.16%
StringHashCode.Algorithm.defaultUTF16	1	-1.57%
StringHashCode.Algorithm.defaultUTF16	10	41.83%
StringHashCode.Algorithm.defaultUTF16	100	80.01%
StringHashCode.Algorithm.defaultUTF16	10000	78.44%

SVE can give notable additional speedup only for very long strings (>1k).

dchuyko · 2024-03-28T12:13:40Z

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp

+  const size_t loop_factor = eltype == T_BOOLEAN || eltype == T_BYTE                    ? 8
+                             : eltype == T_CHAR || eltype == T_SHORT || eltype == T_INT ? 4
+                                                                                        : 0;
+  guarantee(loop_factor, "unsopported eltype");


typo: unsupported

dchuyko · 2024-03-28T15:25:45Z

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp

+   *
+   * Pseudocode:
+   *
+   *  cnt -= unroll_facotor + 1 - loop_factor;


typo: factor

mlbridge · 2024-04-15T22:04:07Z

Webrevs

theRealAph · 2024-04-16T07:36:16Z

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp

+    default: ShouldNotReachHere();
+  }
+
+  /**


// comments here.

theRealAph · 2024-04-16T09:22:49Z

Why are you adding across lanes every time around the loop? You could maintain all of the lanes and then merge the lanes in the tail.

mikabl-arm · 2024-04-16T10:32:35Z

Why are you adding across lanes every time around the loop? You could maintain all of the lanes and then merge the lanes in the tail.

@theRealAph , thank you for a suggestion. That's because current result (hash sum) has to multiplied by 31^4 between iterations, where 4 is the numbers of elements handled per iteration. It's possible to multiply all lanes of vmultiplication register by 31^4 with MUL (vector) or MUL (by element) on each loop iteration and merge them just once in the end as you suggested though. I tried this approach before and it displays worse performance results on the benchmarks compared to the following sequence used in this PR:

    addv(vmultiplication, Assembler::T4S, vmultiplication);                                                                                                                                                                                                                                                                                                                                                                           
    umov(addend, vmultiplication, Assembler::S, 0); // Sign-extension isn't necessary                                                                                                                                                                                                                                                                                                                                                 
    maddw(result, result, pow4, addend);

I can re-check and post the performance numbers here per a request.

theRealAph · 2024-04-16T12:28:14Z

I can re-check and post the performance numbers here per a request.

Please do. Please also post the code.

mikabl-arm · 2024-04-18T16:10:08Z

I can re-check and post the performance numbers here per a request.

Please do. Please also post the code.

@theRealAph , you may find the performance numbers and the code in mikabl-arm@f844b11

theRealAph · 2024-04-19T17:26:27Z

I can re-check and post the performance numbers here per a request.

Please do. Please also post the code.

@theRealAph , you may find the performance numbers and the code in mikabl-arm@f844b11

OK, thanks. I think I see the problem. Unfortunately I've come to the end of my working day, but I'll try to get back to you as soon as possible next week.

theRealAph · 2024-04-22T12:39:45Z

In addition, doing only one vector per iteration is very wasteful. A high-performance AArch64 implementation can issue four multiply-accumulate vector instructions per cycle, with a 3-clock latency. By only issuing a single multiply-accumulate per iteration you're leaving a lot of performance on the table. I'd try to make the bulk width 16, and measure from there.

theRealAph · 2024-04-22T12:51:06Z

You only need one load, add, and multiply per iteration.
You don't need to add across columns until the end.

This is an example of how to do it. The full thing is at https://gist.github.com/theRealAph/cbc85299d6cd24101d46a06c12a97ce6.

    public static int vectorizedHashCode(int result, int[] a, int fromIndex, int length) {
        if (length < WIDTH) {
            return hashCode(result, a, fromIndex, length);
        }
        int offset = fromIndex;
        int[] sum = new int[WIDTH];
        sum[WIDTH - 1] = result;
        int[] temp = new int[WIDTH];
        int remaining = length;
        while (remaining >= WIDTH * 2) {
            vmult(sum, sum, n31powerWIDTH);
            vload(temp, a, offset);
            vadd(sum, sum, temp);
            offset += WIDTH;
            remaining -= WIDTH;
        }
        vmult(sum, sum, n31powerWIDTH);
        vload(temp, a, offset);
        vadd(sum, sum, temp);
        vmult(sum, sum, n31powersToWIDTH);
        offset += WIDTH;
        remaining -= WIDTH;
        result = vadd(sum);
        return hashCode(result, a, fromIndex + offset, remaining);
    }

mikabl-arm · 2024-04-22T14:42:40Z

You only need one load, add, and multiply per iteration.
You don't need to add across columns until the end.

This is an example of how to do it. The full thing is at https://gist.github.com/theRealAph/cbc85299d6cd24101d46a06c12a97ce6.

@theRealAph , looks reasonable, thank you for providing the listing! I'll revert back on this once I have updated performance numbers.

mikabl-arm · 2024-04-22T14:45:49Z

A high-performance AArch64 implementation can issue four multiply-accumulate vector instructions per cycle, with a 3-clock latency.

@theRealAph , hmph, could you elaborate on what spec you refer to here?

theRealAph · 2024-04-22T15:48:32Z

A high-performance AArch64 implementation can issue four multiply-accumulate vector instructions per cycle, with a 3-clock latency.

@theRealAph , hmph, could you elaborate on what spec you refer to here?

That's not so much a spec, more Dougall's measured Apple M1 performance: https://dougallj.github.io/applecpu/measurements/firestorm/UMLAL_v_4S.html.
Other high-end AArch64 designs can't do that, but they won't suffer by going wider. We should be able to sustain pipelined 4 int-wide elements/cycle.

mikabl-arm · 2024-04-24T13:37:10Z

You only need one load, add, and multiply per iteration.
You don't need to add across columns until the end.

@theRealAph , I've tried to follow the suggested approach, please find the patch and result in mikabl-arm@e352f30 .

So far I wasn't able to see any performance benefits compared to an implementations from this MR.

theRealAph · 2024-04-24T16:30:51Z

You only need one load, add, and multiply per iteration.
You don't need to add across columns until the end.

@theRealAph , I've tried to follow the suggested approach, please find the patch and result in mikabl-arm@e352f30 .

So far I wasn't able to see any performance benefits compared to an implementations from this MR.

Yeah, true. I can see why that's happening from prof perfnorm:

   4.30%  ↗   0x0000ffff70b3cdec:   mul		v1.4s, v1.4s, v3.4s
   0.45%  │   0x0000ffff70b3cdf0:   ld1		{v0.4s}, [x1], #16
  81.54%  │   0x0000ffff70b3cdf4:   add		v1.4s, v1.4s, v0.4s
   4.83%  │   0x0000ffff70b3cdf8:   subs		w2, w2, #4
   3.55%  ╰   0x0000ffff70b3cdfc:   b.hs		#0xffff70b3cdec

 ArraysHashCode.ints:IPC               1024  avgt          1.395          insns/clk

This is 1.4 insns/clk on a machine that can run 8 insns/clk. Because we're doing one load, then the MAC, then another load after the MAC, then a MAC that depends on the load: we stall the whole core waiting for the next load. Everything is serialized. Neoverse looks the same as Apple M1 here.

I guess the real question here is what we want. x86's engineers get this:

Benchmark            (size)  Mode  Cnt     Score    Error  Units
ArraysHashCode.ints       1  avgt    5     0.834 ±  0.001  ns/op
ArraysHashCode.ints      10  avgt    5     5.500 ±  0.016  ns/op
ArraysHashCode.ints     100  avgt    5    20.330 ±  0.103  ns/op
ArraysHashCode.ints   10000  avgt    5  1365.347 ±  1.045  ns/op

(And that's on my desktop box from 2018, an inferior piece of hardware.)

This is how they do it:

          ↗  0x00007f0634c21c17:   imul   ebx,r11d
   0.02%  │  0x00007f0634c21c1b:   vmovdqu ymm12,YMMWORD PTR [rdi+rsi*4]
          │  0x00007f0634c21c20:   vmovdqu ymm2,YMMWORD PTR [rdi+rsi*4+0x20]
   5.36%  │  0x00007f0634c21c26:   vmovdqu ymm0,YMMWORD PTR [rdi+rsi*4+0x40]
          │  0x00007f0634c21c2c:   vmovdqu ymm1,YMMWORD PTR [rdi+rsi*4+0x60]
   0.05%  │  0x00007f0634c21c32:   vpmulld ymm8,ymm8,ymm3
  11.12%  │  0x00007f0634c21c37:   vpaddd ymm8,ymm8,ymm12
   4.97%  │  0x00007f0634c21c3c:   vpmulld ymm9,ymm9,ymm3
  15.09%  │  0x00007f0634c21c41:   vpaddd ymm9,ymm9,ymm2
   5.16%  │  0x00007f0634c21c45:   vpmulld ymm10,ymm10,ymm3
  15.51%  │  0x00007f0634c21c4a:   vpaddd ymm10,ymm10,ymm0
   5.44%  │  0x00007f0634c21c4e:   vpmulld ymm11,ymm11,ymm3
  16.39%  │  0x00007f0634c21c53:   vpaddd ymm11,ymm11,ymm1
   4.80%  │  0x00007f0634c21c57:   add    esi,0x20
          │  0x00007f0634c21c5a:   cmp    esi,ecx
          ╰  0x00007f0634c21c5c:   jl     0x00007f0634c21c17

So, do we want to try to beat them on Arm, or not? They surely want to beat Arm.

theRealAph · 2024-05-10T07:49:32Z

Hi, is this one stuck? What you have today is definitely an improvement, even though it's not as good as what we have for x86. I guess we could commit this and leave widening the arithmetic for a later enhancement if you have no time to work on it.

…lements modulo vf

adinn

Thanks for the final cleanups. All looking very nice!

src/hotspot/share/utilities/intpow.hpp

test/hotspot/gtest/aarch64/aarch64-asmtest.py

Co-authored-by: Andrew Haley <aph-open@littlepinkcloud.com>

mikabl-arm · 2024-09-26T12:32:08Z

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

+      } else {
+        __ uxtl(vhalf0, Assembler::T4S, vdata0, Assembler::T4H);
+      }
+      __ addv(vmul0, Assembler::T4S, vmul0, vhalf0);


I was advised to use a single SADDW/UADDW instruction instead of the current pair of SXTL/UXTL followed by ADD. It seems this was likely overlooked because the Assembler class is missing the corresponding instructions. I am adding these instructions and updating the implementation accordingly.

Done by 03849d6 .

This improves the performance for T_BOOLEAN/T_BYTE and T_CHAR/T_SHORT arrays compared to the previous implementation (bfa9369).

ArraysHashCode-v2-03849d6.txt

src/hotspot/cpu/aarch64/assembler_aarch64.hpp

theRealAph · 2024-09-27T12:48:37Z

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

+      if (is_signed_subword_type(eltype)) {
+        __ saddwv2(vmul0, vmul0, Assembler::T4S, vdata0, Assembler::T8H);
+      } else {
+        __ uaddwv2(vmul0, vmul0, Assembler::T4S, vdata0, Assembler::T8H);
+      }


Maybe define addwv2 and addwv in MacroAssembler.

Suggested change

if (is_signed_subword_type(eltype)) {

__ saddwv2(vmul0, vmul0, Assembler::T4S, vdata0, Assembler::T8H);

} else {

__ uaddwv2(vmul0, vmul0, Assembler::T4S, vdata0, Assembler::T8H);

}

__ addwv2(is_signed_subword_type(eltype), vmul0, vmul0, Assembler::T4S, vdata0, Assembler::T8H);

I believe that an interface should be explicit and map 1:1 to real instructions when it comes to assembly whereas possible.

Anyway, regardless of my preferences, as far as I can see, currently Assembler provides all other signed/unsigned versions of arithmetic instructions separately. Adding a single method like this would make the whole API inconsistent. Therefore, I suggest leaving it as is.

I have no problem at all with what class Assembler provides. However, when the result looks like this, even a "normal" assembler programmer would suggest macros rather than copy-and-paste:

assert(is_subword_type(eltype), "subword type expected"); if (is_signed_subword_type(eltype)) { __ saddwv(vmul3, vmul3, Assembler::T4S, vdata3, Assembler::T4H); __ saddwv(vmul2, vmul2, Assembler::T4S, vdata2, Assembler::T4H); __ saddwv(vmul1, vmul1, Assembler::T4S, vdata1, Assembler::T4H); __ saddwv(vmul0, vmul0, Assembler::T4S, vdata0, Assembler::T4H); } else { __ uaddwv(vmul3, vmul3, Assembler::T4S, vdata3, Assembler::T4H); __ uaddwv(vmul2, vmul2, Assembler::T4S, vdata2, Assembler::T4H); __ uaddwv(vmul1, vmul1, Assembler::T4S, vdata1, Assembler::T4H); __ uaddwv(vmul0, vmul0, Assembler::T4S, vdata0, Assembler::T4H); }

Would it be possible to integrate this as is? The code was approved twice before, even though it had the same constructs.

OK. It's a fairly minor style thing, something to remember for the future.

Co-authored-by: Andrew Haley <aph-open@littlepinkcloud.com>

mikabl-arm · 2024-09-30T08:57:27Z

/integrate

openjdk · 2024-09-30T08:59:04Z

@mikabl-arm
Your change (at version 1dbb1dd) is now ready to be sponsored by a Committer.

theRealAph · 2024-09-30T09:00:58Z

/sponsor

openjdk · 2024-09-30T09:02:59Z

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

52ba728: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
988a531: 8340181: Shenandoah: Cleanup ShenandoahRuntime stubs
822a773: 8340605: Open source several AWT PopupMenu tests
6514aef: 8340419: ZGC: Create an UseLargePages adaptation of TestAllocateHeapAt.java
ae4d2f1: 8340621: Open source several AWT List tests
dd56990: 8340639: Open source few more AWT List tests
ade17ec: 8340560: Open Source several AWT/2D font and rendering tests
73ebb84: 8340721: Clarify special case handling of unboxedType and getWildcardType
ed140f5: 8341101: [ARM32] Error: ShouldNotReachHere() in TemplateInterpreterGenerator::generate_math_entry after 8338694
082125d: 8340404: CharsetProvider specification updates
... and 155 more: https://git.openjdk.org/jdk/compare/4ff17c14a572a59b60d728c3626f430932eecea6...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-09-30T09:03:07Z

@theRealAph @mikabl-arm Pushed as commit 475b894.

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

bridgekeeper bot added the oca Needs verification of OCA signatory status label Mar 26, 2024

openjdk bot added the hotspot hotspot-dev@openjdk.org label Mar 26, 2024

bridgekeeper bot added the oca-verify Needs verification of OCA signatory status label Mar 26, 2024

mikabl-arm changed the title ~~8322770: AArch64: C2: Implement VectorizedHashCode~~ 8322770: Implement C2 VectorizedHashCode on AArch64 Mar 26, 2024

dchuyko reviewed Mar 28, 2024

View reviewed changes

bridgekeeper bot removed oca Needs verification of OCA signatory status oca-verify Needs verification of OCA signatory status labels Apr 15, 2024

openjdk bot added the rfr Pull request is ready for review label Apr 15, 2024

theRealAph reviewed Apr 16, 2024

View reviewed changes

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp Outdated

default: ShouldNotReachHere();

}

/**

Copy link

Contributor

theRealAph Apr 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// comments here.

cleanup: explain how this deals with the correct number of leftover e…

142fa5d

…lements modulo vf

adinn approved these changes Sep 25, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 25, 2024

theRealAph reviewed Sep 26, 2024

View reviewed changes

src/hotspot/share/utilities/intpow.hpp Show resolved Hide resolved

theRealAph reviewed Sep 26, 2024

View reviewed changes

test/hotspot/gtest/aarch64/aarch64-asmtest.py Show resolved Hide resolved

cleanup: add a description for intpow()

6f2bec3

Co-authored-by: Andrew Haley <aph-open@littlepinkcloud.com>

openjdk bot removed the ready Pull request is ready to be integrated label Sep 26, 2024

mikabl-arm commented Sep 26, 2024

View reviewed changes

Add and use Add Wide insts instead of pairs of Extend/Shift + Add

03849d6

openjdk bot removed the rfr Pull request is ready for review label Sep 27, 2024

cleanup: formatting

b55d4ba

openjdk bot added the rfr Pull request is ready for review label Sep 27, 2024

fixup: use xaddwv2 where required in unit tests

7d1c6b7

theRealAph reviewed Sep 27, 2024

View reviewed changes

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

theRealAph reviewed Sep 27, 2024

View reviewed changes

cleanup: collapse duplicated code into a macro

1dbb1dd

Co-authored-by: Andrew Haley <aph-open@littlepinkcloud.com>

theRealAph approved these changes Sep 27, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 27, 2024

openjdk bot added the sponsor Pull request is ready to be sponsored label Sep 30, 2024

openjdk bot added the integrated Pull request has been integrated label Sep 30, 2024

openjdk bot closed this Sep 30, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Sep 30, 2024

mikabl-arm mentioned this pull request Oct 1, 2024

8341194: [REDO] Implement C2 VectorizedHashCode on AArch64 #21286

Closed

3 tasks

8322770: Implement C2 VectorizedHashCode on AArch64 #18487

8322770: Implement C2 VectorizedHashCode on AArch64 #18487

Uh oh!

Conversation

mikabl-arm commented Mar 26, 2024 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Performance

Neoverse N1

Neoverse N2, Neoverse V1

Test

Progress

Issue

Reviewers

Reviewing

Webrev

Uh oh!

bridgekeeper bot commented Mar 26, 2024

Uh oh!

openjdk bot commented Mar 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Mar 26, 2024

Uh oh!

mikabl-arm commented Mar 26, 2024

Uh oh!

bridgekeeper bot commented Mar 26, 2024

Uh oh!

dchuyko commented Mar 28, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mlbridge bot commented Apr 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

theRealAph commented Apr 16, 2024

Uh oh!

mikabl-arm commented Apr 16, 2024

Uh oh!

theRealAph commented Apr 16, 2024

Uh oh!

mikabl-arm commented Apr 18, 2024

Uh oh!

theRealAph commented Apr 19, 2024

Uh oh!

theRealAph commented Apr 22, 2024

Uh oh!

theRealAph commented Apr 22, 2024

Uh oh!

mikabl-arm commented Apr 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mikabl-arm commented Apr 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theRealAph commented Apr 22, 2024

Uh oh!

mikabl-arm commented Apr 24, 2024

Uh oh!

theRealAph commented Apr 24, 2024

Uh oh!

theRealAph commented May 10, 2024

Uh oh!

adinn left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

mikabl-arm commented Mar 26, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Mar 26, 2024 •

edited

Loading

mlbridge bot commented Apr 15, 2024 •

edited

Loading

mikabl-arm commented Apr 22, 2024 •

edited

Loading

mikabl-arm commented Apr 22, 2024 •

edited

Loading