-
Enhancement
-
Resolution: Unresolved
-
P4
-
26
In JDK-8324751, we are integrating the TestAliasingFuzzer.java
There is a "Future Work" section at the top of the test, with many ideas. Some I repeat here:
1) check for no multiversioning
-------------------------------------------
I also had to fix the TestAliasingFuzzer.java: I can no longer assert that there is no multiversioning because there are some edge-cases where we have issues. I filed bugs for those, and already integrated an IR test for each.
https://bugs.openjdk.org/browse/JDK-8360204
https://bugs.openjdk.org/browse/JDK-8365982
There may be more such issues.
Asserting that there is no multiversioning in the IR rules makes sure that we made the runtime check as exact as possible, and do not fail in cases where it would have been safe to keep the predicate, rather than deoptimizing and compiling with multiversioning (more compile time, more code -> just worse).
2) check for load/store vectors
-------------------------------------------
JDK-8359688
Additionally, you may be able to add IR rules checking for load/store vectors in:
- generateIRRulesMemorySegmentAtIndex
- generateIRRulesMemorySegmentLongAdrScale
- generateIRRulesMemorySegmentLongAdrStride
3) Create more cases (future work section)
------------------------------------------------------------
Especially to catch bugs likeJDK-8369902
But we should be careful not to destroy the current test, and for that, we should probably make sure we can enable the IR rules first.
There is a "Future Work" section at the top of the test, with many ideas. Some I repeat here:
1) check for no multiversioning
-------------------------------------------
I also had to fix the TestAliasingFuzzer.java: I can no longer assert that there is no multiversioning because there are some edge-cases where we have issues. I filed bugs for those, and already integrated an IR test for each.
https://bugs.openjdk.org/browse/JDK-8360204
https://bugs.openjdk.org/browse/JDK-8365982
There may be more such issues.
Asserting that there is no multiversioning in the IR rules makes sure that we made the runtime check as exact as possible, and do not fail in cases where it would have been safe to keep the predicate, rather than deoptimizing and compiling with multiversioning (more compile time, more code -> just worse).
2) check for load/store vectors
-------------------------------------------
JDK-8359688
Additionally, you may be able to add IR rules checking for load/store vectors in:
- generateIRRulesMemorySegmentAtIndex
- generateIRRulesMemorySegmentLongAdrScale
- generateIRRulesMemorySegmentLongAdrStride
3) Create more cases (future work section)
------------------------------------------------------------
Especially to catch bugs like
But we should be careful not to destroy the current test, and for that, we should probably make sure we can enable the IR rules first.
- is blocked by
-
JDK-8359688 C2 SuperWord: missing RCE with MemorySegment
-
- Open
-
-
JDK-8360204 C2 SuperWord: missing RCE with MemorySegment.getAtIndex
-
- Open
-
-
JDK-8365982 C2 SuperWord: missing RCE / strange Multiversioning with MemorySegment.set
-
- Open
-
-
JDK-8324751 C2 SuperWord: Aliasing Analysis runtime check
-
- Resolved
-