RFR: 8285790: AArch64: Merge C2 NEON and SVE matching rules

[Ningsheng Jian]

On Wed, 27 Jul 2022 10:23:16 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> 
> 1. How good is our overall coverage for Neon
> 2. Are there rules for specific operations that you think are not well covered.

Thank you @adinn for the review! @shqking is taking leave, so I will try to answer the questions.

I agree that it's not easy to spot more issues on the big patch. Though @theRealELiu and I also reviewed the whole patchset several times, we still got an issue during the latest round of tests, when the option MaxVectorSize=8 is specified. Fixed in the new commit.

And yes, "Test coverage" is very important to us when we started this refactoring work. Before @shqking 's vacation, we had a review of the coverage, and here's the summary:

1. Can all the matching rules be covered by existing JTreg test cases?

It's not an easy question to answer due to the big number of rules. Here is the conclusion based on our testing and experience.

a) Vector API provides systematic test cases to cover most of rules, except for some chain rules, e.g., 
`// vector add reg imm (unpredicated)` rules and `MLA RELATED` rules.

b) We manually checked those chain rules, and found most of them were covered by jtreg tests as well.
E.g.,
`test/hotspot/jtreg/compiler/codegen/TestByteVect.java` was designed for `// vector add reg imm (unpredicated)` rules, while Vector API test cases for `broadcast(imm)` can cover `// replicate from imm` rules.

We can see only `fabd` rule is not covered so far. We've tested it with a new case - note that currently only NEON version is supported, and we plan to support SVE `fabd` after this refactoring patch. We may add the corresponding test cases in that patch.

2. What kinds of platforms are tested?

a) Linux x86: cross compilation of arm32, ppc64, s390, riscv64. All passed.
b) We ran Jtreg `tier1~3` on the following platforms, and no new failures.
  - Linux x86
  - Linux AArch64 NEON only platform
  - Linux AArch64 NEON only platform with `-XX:MaxVectorSize=8`
  - Linux 512-bit SVE platform
  - Linux 256-bit SVE platform
  - Linux 256-bit SVE platform with `-XX:UseSVE=0`
  - Linux 256-bit SVE platform with `-XX:MaxVectorSize=8`
  - Linux 256-bit SVE platform with `-XX:MaxVectorSize=16`

c) JMH testing
We choose vector micro-benchmarks from panama-vector:vectorIntrinsics [1] to evaluate the performance of this
patch. We've tested *MaxVectorTests.java cases on one 128-bit SVE platform and one NEON platform, and didn't
see any visible regression with NEON and SVE.

3. TODOs, before integration:

a). If possible, we will ask Oracle engineers to help run tests with this patch which may include different tests.
b). We will continue to conduct more performance testings with NEON and different SVE vector sizes on different hardware.

[1] https://github.com/openjdk/panama-vector/tree/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation

-------------

PR: https://git.openjdk.org/jdk/pull/9346