RFR: 8371768: AArch64: test/hotspot/jtreg/compiler/loopopts/superword/TestReductions.java fails on SVE after JDK-8340093

Tue Nov 25 11:16:28 UTC 2025

On Thu, 20 Nov 2025 11:02:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks like the test should be more resilient with UseSVE > 0, which _can_ vectorise. It does not look all that reliable to me to failOn when vectorization actually happens. So I dropped some non-arch-specific rules, and amended AArch64-specific rules for UseSVE.
> 
> Testing:
>  - [x] Linux AArch64 server fastdebug, affected test on machine with UseSVE=1 by default
>  - [x] Linux AArch64 server fastdebug, affected test on machine with UseSVE=0 overridden

@shipilev Thanks for working on this! It is really largely my fault: I did not run testing for this test with SVE (I have no SVE machine), and also failed to ask externals to run testing. My bad, I will do better next time 🙈 

However, I think there is some level of misunderstanding I hope to clear up below.

In the time since this issue was filed, I finally learned how to use QEMU to run with SVE. So if this is all too much for you here, I could try to run this through QEMU and fix the rules.

Background on `failOn`, or what I call "negative tests":
I have found it quite helpful to not just test where optimization succeed, but also whee they fail, for some reason we can fix in the future. If anyone ever fixes the issue, then the IR rule fails. One can then go read the description, and even find the issue number. This allows us to detect that one might have fixed another issue, and close that as a duplicate. One would then be expected to adjust the IR rule and turn it from negative to positive.

What do you think? Does that make sense to you?

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

> Looks like the test should be more resilient with UseSVE > 0, which can vectorise.

I only ran testing on NEON, so there are most likely some cases that vectorize with SVE but not NEON.

The example I can find on JIRA right now:

1) Method "private static double compiler.loopopts.superword.TestReductions.doubleAddBig()" - [Failed IR rules: 1]:
   * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={}, applyIfPlatformOr={}, applyIfPlatform={}, failOn={"_#V#L
OAD_VECTOR_D#_"}, applyIfOr={}, applyIfCPUFeatureAnd={"asimd", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
     > Phase "PrintIdeal":
       - failOn: Graph contains forbidden nodes:
         * Constraint 1: "(\d+(\s){2}(LoadVector.*)+(\s){2}===.*vector[A-Za-z]<D,\d+>)"
           - Matched forbidden nodes (18):
             * 1125 LoadVector === 857 7 874 |351 [[ 1127 1129 ]] @double[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=7; mismatched #vectorx<
D,2>

This comes from that rule:

    @IR(failOn = IRNode.LOAD_VECTOR_D,
        applyIfCPUFeatureAnd = {"asimd", "true"})
    // I think this could vectorize, but currently does not. Filed: JDK-8370677
    // But: it is not clear that it would be profitable, given the sequential reduction.

Turns out this rule passes with NEON, but fails with SVE.
Now you just removed the rule, together with my comments. I would prefer if we make the IR rules more specific, using `UseSVE=0`.

Interestingly, that is what you did for `doubleMulBig`:
<img width="797" height="343" alt="image" src="https://github.com/user-attachments/assets/0c554383-7d4b-4c38-ae4b-534fdea66413" />

You could then write a IR rule that works for `UseSVE>0`, if you like. Or not if you don't care. Up to you.

> It does not look all that reliable to me to failOn when vectorization actually happens.

It is not that this rule is "unreliable", it is simply wrong for SVE ;)

But one rule that should not be incorrect, and you now removed it in many places:

    @IR(failOn = IRNode.LOAD_VECTOR_D,
        applyIf = {"AutoVectorizationOverrideProfitability", "= 0"})

Did you ever see these fail? Because `AutoVectorizationOverrideProfitability=0` disables vectorization, and so you really should not see any vectors here.

@shipilev One "quick fix" in case this just creates too much noise in your CI: just add a `@requires` that disables running the test on SVE. Then we can fix the IR rules later and enable the test for SVE again.

test/hotspot/jtreg/compiler/loopopts/superword/TestReductions.java line 1234:

> 1232:         applyIf = {"AutoVectorizationOverrideProfitability", "> 0"})
> 1233:     @IR(failOn = IRNode.LOAD_VECTOR_I,
> 1234:         applyIf = {"AutoVectorizationOverrideProfitability", "= 0"})

Did this rule ever fail? `AutoVectorizationOverrideProfitability=0` means we should NOT vectorize on any platform. That should also not happen with SVE.

test/hotspot/jtreg/compiler/loopopts/superword/TestReductions.java line 1238:

> 1236:                   IRNode.MUL_VI,           "> 0"},
> 1237:         applyIfCPUFeatureOr = {"asimd", "true"},
> 1238:         applyIfAnd = {"AutoVectorizationOverrideProfitability", "> 0", "UseSVE", "0"})

You could add specific IR rules for specific lengths, using `IRNode.VECTOR_SIZE`, just grep for it, there are multiple tests.

This also sounds like we should file a follow-up RFE? That was the whole point of the very specific IR rules: we want to have an overview what things do vectorize, and at what vector length: hopefully at the longest that the platform supports.

test/hotspot/jtreg/compiler/loopopts/superword/TestReductions.java line 1608:

> 1606:     //       cannot use the MulVL as the vector accumulator.
> 1607:     @IR(failOn = IRNode.LOAD_VECTOR_L,
> 1608:         applyIf = {"AutoVectorizationOverrideProfitability", "= 0"})

Same comment about `AutoVectorizationOverrideProfitability=0`: it should not vectorize on any platform.

Also: why did you remove my comment about NEON?

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28423#pullrequestreview-3504489937
PR Comment: https://git.openjdk.org/jdk/pull/28423#issuecomment-3575097794
PR Review Comment: https://git.openjdk.org/jdk/pull/28423#discussion_r2559526184
PR Review Comment: https://git.openjdk.org/jdk/pull/28423#discussion_r2559536779
PR Review Comment: https://git.openjdk.org/jdk/pull/28423#discussion_r2559540428