Bug ID: JDK-8337817 Incorrect result computation in vector tests with MaxVectorSize=8

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 17,21,23,24

Priority: P3
Status: Closed
Resolution: Duplicate
CPU: x86_64

Submitted: 2024-08-05
Updated: 2024-08-12
Resolved: 2024-08-12

JDK 24
24Resolved

Following tests fails when MaxVectorSize is set to 8 bytes

compiler/loopopts/superword/TestMulAddS2I.java
compiler/vectorization/TestFloatConversionsVector.java


Test Failures (1)
-----------------
Custom Run Test: @Run: run - @Tests: {testa,testb,testc,testd,teste,testf,testg,testh,testi,testj,testk,testl}:
compiler.lib.ir_framework.shared.TestRunException: There was an error while invoking @Run method public static void compiler.loopopts.superword.TestMulAddS2I.run()
        at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:162)
        at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:103)
        at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89)
        at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:861)
        at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:252)
        at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:165)
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
        at java.base/java.lang.reflect.Method.invoke(Method.java:588)
        at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:159)
        ... 5 more
Caused by: java.lang.RuntimeException: wrong result for 'testk' out[2] expected: 667396746 but was: 388519276
        at jdk.test.lib.Asserts.fail(Asserts.java:691)

Thanks!
12-08-2024
Ok, converted the sub-tasks into bugs. We can now close this one as a duplicate of those two.
12-08-2024
[~epeter] It seems that the two bugs are not really related, correct? I would therefore suggest to convert the sub-tasks to standalone bugs.
12-08-2024
[~jbhateja][~thartmann][~kvn] Turns out these are 2 old bugs. I filed corresponding subtasks. Both do not really require MaxVectorSize=8, that flag just easily revealed the bugs. But I have regression tests that fail without that flag now.
09-08-2024
Concerning "TestMulAddS2I.java": I created a Test1b.java, which also reproduces without -XX:MaxVectorSize=8 java -XX:CompileCommand=printcompilation,Test1b::* -XX:CompileCommand=compileonly,Test1b::testk -Xbatch -XX:LoopMaxUnroll=8 -XX:+TraceNewVectors Test1b.java It looks like the fix of JDK-8333840 was incomplete / had a typo. https://github.com/openjdk/jdk/commit/b09a45163ccc566b4f7653c2e9030e359396c90f The change below would fix it, I think: diff --git a/src/hotspot/share/opto/superword.cpp b/src/hotspot/share/opto/superword.cpp index 0e1328a4485..5b420487b06 100644 --- a/src/hotspot/share/opto/superword.cpp +++ b/src/hotspot/share/opto/superword.cpp @@ -2272,7 +2272,7 @@ Node_List* PackSet::strided_pack_input_at_index_or_null(const Node_List* pack, c return nullptr; // size mismatch } - for (uint i = 1; i < pack->size(); i++) { + for (uint i = 0; i < pack->size(); i++) { if (pack->at(i)->in(index) != pack_in->at(i * stride + offset)) { return nullptr; // use-def mismatch } Now, since JDK-8333840 is not yet backported, the versions 17, 21, 22, 23 are still affected - and so also our Test1b.java fails there.
09-08-2024
Update on "TestFloatConversionsVector.java": It seems that we are using this instruction: https://www.felixcloutier.com/x86/vcvtps2ph But it only has 4, 8 and 16 element variants. No 2-element variant available. But since we have MaxVectorSize=8, we can only fit 2 elements. Somehow we vectorize that still. The consequence: a 4-element vector is used, and 8 bytes are stored instead of 4 bytes. The lower 4 bytes have the correct values, but the upper 4 bytes are incorrect. I tried to shuffle the order of the stores with "-XX:+StressGCM -XX:+StressLCM -XX:+StressIGVN", and suddenly the wrong execution also shows up not just for JDK24, but JDK23-JDK21. JDK17 does not yet have the relevant instruction "Float.floatToFloat16", so the test does not even compile there. It seems this might have been a bug since the first implementation of that feature. I now constructed a different test that always generates 2-element vectors: Test2b.java, and that one consistently produces wrong results, for JDK24-JDK21. /oracle-work/jdk-22.0.2/fastdebug/bin/java -XX:CompileCommand=printcompilation,Test2b::test -XX:CompileCommand=compileonly,Test2b::test -Xbatch -XX:+TraceNewVectors Test2b.java And actually, no flags are even needed here: /oracle-work/jdk-22.0.2/fastdebug/bin/java Test2b.java Indeed, it looks like a regression of JDK-8289552, which was introduced in JDK20. https://github.com/openjdk/jdk/commit/07946aa49c97c93bd11675a9b0b90d07c83f2a94 https://git.openjdk.org/jdk/pull/9781
09-08-2024
I think these are most likely two separate bugs, one for "TestMulAddS2I.java" (since at least JDK17) and one for "TestFloatConversionsVector.java" (probably regression in JDK23 or JDK24).
08-08-2024
For "TestFloatConversionsVector.java", I extracted a "Test2.java". With "-Xint", it passes: ./java -XX:CompileCommand=printcompilation,Test2::* -XX:CompileCommand=compileonly,Test2::* -Xbatch -XX:MaxVectorSize=8 -XX:+TraceNewVectors -Xint Test2.java ./java -XX:CompileCommand=printcompilation,Test2::* -XX:CompileCommand=compileonly,Test2::* -Xbatch -XX:MaxVectorSize=8 -XX:+TraceNewVectors Test2.java This vectorizes, and then generates wrong results. This only seems to fail on master, not with any older jdk. We should run a build-search to find what caused this regression.
08-08-2024
I extracted a simple "Test1.java" from "TestMulAddS2I.java". It seems quite a lot of versions are affected - so probably not a new regression. With -Xint it does not reproduce. With "-XX:-UseSuperWord" it also does not reproduce. There is vectorization, even though there really should not be, the "TestMulAddS2I::testk" has a corresponding comment: "// Unrolled, with some swaps that prevent vectorization." The tests are relatively new, and we do not by standard test with "-XX:MaxVectorSize=8". Maybe we should, at least occasionally. emanuel@emanuel-oracle:/oracle-work/jdk-fork4/build/linux-x64-debug/jdk/bin$ ./java -XX:CompileCommand=printcompilation,Test1::* -XX:CompileCommand=compileonly,Test1::testk -Xbatch -XX:MaxVectorSize=8 Test1.java CompileCommand: PrintCompilation Test1.* bool PrintCompilation = true CompileCommand: compileonly Test1.testk bool compileonly = true 4883 98 % b 3 Test1::testk @ 2 (111 bytes) 4885 99 b 3 Test1::testk (111 bytes) 4888 100 % b 4 Test1::testk @ 2 (111 bytes) 4923 101 b 4 Test1::testk (111 bytes) Exception in thread "main" java.lang.RuntimeException: wrong value: testk i=2 out_i=41 golden_i=40 at Test1.compare(Test1.java:27) at Test1.main(Test1.java:20) emanuel@emanuel-oracle:/oracle-work/jdk-fork4/build/linux-x64-debug/jdk/bin$ /oracle-work/jdk-22.0.1/fastdebug/bin/java -XX:CompileCommand=printcompilation,Test1::* -XX:CompileCommand=compileonly,Test1::testk -Xbatch -XX:MaxVectorSize=8 Test1.java CompileCommand: PrintCompilation Test1.* bool PrintCompilation = true CompileCommand: compileonly Test1.testk bool compileonly = true 2320 105 % b 3 Test1::testk @ 2 (111 bytes) 2322 106 b 3 Test1::testk (111 bytes) 2325 107 % b 4 Test1::testk @ 2 (111 bytes) 2354 108 b 4 Test1::testk (111 bytes) Exception in thread "main" java.lang.RuntimeException: wrong value: testk i=2 out_i=41 golden_i=40 at Test1.compare(Test1.java:27) at Test1.main(Test1.java:20) emanuel@emanuel-oracle:/oracle-work/jdk-fork4/build/linux-x64-debug/jdk/bin$ /oracle-work/jdk-21.0.3/fastdebug/bin/java -XX:CompileCommand=printcompilation,Test1::* -XX:CompileCommand=compileonly,Test1::testk -Xbatch -XX:MaxVectorSize=8 Test1.java CompileCommand: PrintCompilation Test1.* bool PrintCompilation = true CompileCommand: compileonly Test1.testk bool compileonly = true 2269 104 % b 3 Test1::testk @ 2 (111 bytes) 2270 105 b 3 Test1::testk (111 bytes) 2273 106 % b 4 Test1::testk @ 2 (111 bytes) 2298 107 b 4 Test1::testk (111 bytes) Exception in thread "main" java.lang.RuntimeException: wrong value: testk i=2 out_i=41 golden_i=40 at Test1.compare(Test1.java:27) at Test1.main(Test1.java:20) emanuel@emanuel-oracle:/oracle-work/jdk-fork4/build/linux-x64-debug/jdk/bin$ /oracle-work/jdk-17.0.8/fastdebug/bin/java -XX:CompileCommand=printcompilation,Test1::* -XX:CompileCommand=compileonly,Test1::testk -Xbatch -XX:MaxVectorSize=8 Test1.java CompileCommand: An error occurred during parsing Error: Unrecognized option 'printcompilation' Line: 'printcompilation,Test1::*' Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>' Use: '-XX:CompileCommand=help' for more information and to list all option. CompileCommand: compileonly Test1.testk bool compileonly = true Exception in thread "main" java.lang.RuntimeException: wrong value: testk i=2 out_i=41 golden_i=40 at Test1.compare(Test1.java:27) at Test1.main(Test1.java:20)
07-08-2024
It's only MaxVectorSize=8, I verified for triaging.
07-08-2024
[~jbhateja] Is it only MaxVectorSize = 8 or other flags were also use (UseAVX)?
06-08-2024
ILW = Incorrect result with C2 compiled code, two tests with -XX:MaxVectorSize=8, disable compilation or superword = HLM = P3
06-08-2024

Duplicate :	JDK-8338126 - C2 SuperWord: VectorCastF2HF / vcvtps2ph produces wrong results for vector length 2
Duplicate :	JDK-8338124 - C2 SuperWord: MulAddS2I input permutation still partially broken after JDK-8333840