Other |
---|
tbdUnresolved |
Blocks :
|
|
Blocks :
|
|
Blocks :
|
|
Blocks :
|
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 like JDK-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.