JDK-8353058 : [PPC64] Some IR framework tests are failing after JDK-8314999
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • CPU: ppc
  • Submitted: 2025-03-27
  • Updated: 2025-03-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25Unresolved
Related Reports
Relates :  
JDK-8352595 - Regression of JDK-8314999 in IR matching
Relates :  
JDK-8352650 - Some IR framework tests are failing after JDK-8314999
Relates :  
JDK-8314999 - IR framework fails to detect allocation
Description
testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java is still failing on PPC64 after JDK-8314999:

"Expected Failures" WITHOUT "Found Failures":
Failure[methodName=defaultOnBoth, irRuleId=3, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2]
Failure[methodName=defaultOnBoth, irRuleId=4, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2]
Failure[methodName=defaultOnBoth, irRuleId=5, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=1]
Failure[methodName=defaultOnOptoAssembly, irRuleId=1, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=FAIL_ON, constraintId=2]
Failure[methodName=defaultOnOptoAssembly, irRuleId=2, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=FAIL_ON, constraintId=2]
Failure[methodName=defaultOnOptoAssembly, irRuleId=4, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=FAIL_ON, constraintId=2]
"Found Failures" WITHOUT "Expected Failures":
Failure[methodName=defaultOnBoth, irRuleId=1, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2]
Failure[methodName=defaultOnOptoAssembly, irRuleId=1, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2]
Failure[methodName=defaultOnOptoAssembly, irRuleId=3, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2]
Comments
ILW = Failing IR framework internal test on PPC, single test, no workaround = MLH = P4
31-03-2025
Awesome! I can create a PR for it later and also run some testing in our CI since this proposed change affects all the platforms.
31-03-2025
This works on PPC64! Thank you so much!
31-03-2025
I've had another look at the test. I cannot remember why I've chosen the rules to fail in the way they do. defaultOnX() suggests that we should only see failures on phase X but we do not really follow that. All three tests kinda mix ideal and mach failures together. I therefore suggest to clean this up such that we follow the original (?) idea of only seeing failures for X. Here is a draft: https://github.com/openjdk/jdk/commit/896b77731a9819fcce2e9c35191976ada4115c6b Can you check if that works on PPC?
31-03-2025
Thanks for the hints! I can get defaultOnBoth tests to work with the patch below. Do you also have an idea for the failing defaultOnOptoAssembly tests? I don't really know which numbers to change in which way. "Expected Failures" WITHOUT "Found Failures": Failure[methodName=defaultOnOptoAssembly, irRuleId=1, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=FAIL_ON, constraintId=2] Failure[methodName=defaultOnOptoAssembly, irRuleId=2, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=FAIL_ON, constraintId=2] Failure[methodName=defaultOnOptoAssembly, irRuleId=4, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=FAIL_ON, constraintId=2] "Found Failures" WITHOUT "Expected Failures": Failure[methodName=defaultOnOptoAssembly, irRuleId=1, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2] Failure[methodName=defaultOnOptoAssembly, irRuleId=3, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2] diff --git a/test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java b/test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java index f2dd871ae83..4b66268304a 100644 --- a/test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java +++ b/test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java @@ -172,23 +172,23 @@ public Object defaultOnOptoAssembly(Helper h) { @Test @IR(failOn = {IRNode.STORE, IRNode.FIELD_ACCESS, IRNode.COUNTED_LOOP}, counts = {IRNode.STORE, "20", IRNode.FIELD_ACCESS, "3", IRNode.COUNTED_LOOP, "2"}) - @ExpectedFailure(ruleId = 1, phase = CompilePhase.PRINT_OPTO_ASSEMBLY, failOn = 2) + @ExpectedFailure(ruleId = 1, phase = CompilePhase.PRINT_OPTO_ASSEMBLY, failOn = 2, counts = 2) @ExpectedFailure(ruleId = 1, phase = CompilePhase.PRINT_IDEAL, failOn = 1, counts = {1, 3}) @IR(failOn = {IRNode.STORE, IRNode.FIELD_ACCESS, IRNode.COUNTED_LOOP}) @ExpectedFailure(ruleId = 2, phase = CompilePhase.PRINT_IDEAL, failOn = 1) @ExpectedFailure(ruleId = 2, phase = CompilePhase.PRINT_OPTO_ASSEMBLY, failOn = 2) - @IR(counts = {IRNode.STORE, "20", IRNode.FIELD_ACCESS, "2", IRNode.COUNTED_LOOP, "2"}) + @IR(counts = {IRNode.STORE, "20", IRNode.FIELD_ACCESS, "4", IRNode.COUNTED_LOOP, "2"}) @ExpectedFailure(ruleId = 3, phase = CompilePhase.PRINT_IDEAL, counts = {1, 3}) @ExpectedFailure(ruleId = 3, phase = CompilePhase.PRINT_OPTO_ASSEMBLY, counts = 2) @IR(failOn = {IRNode.STORE, IRNode.FIELD_ACCESS, IRNode.COUNTED_LOOP}, - counts = {IRNode.STORE, "20", IRNode.FIELD_ACCESS, "2", IRNode.COUNTED_LOOP, "2"}) + counts = {IRNode.STORE, "20", IRNode.FIELD_ACCESS, "4", IRNode.COUNTED_LOOP, "2"}) @ExpectedFailure(ruleId = 4, phase = CompilePhase.PRINT_OPTO_ASSEMBLY, failOn = 2, counts = 2) @ExpectedFailure(ruleId = 4, phase = CompilePhase.PRINT_IDEAL, failOn = 1, counts = {1, 3}) - @IR(counts = {IRNode.FIELD_ACCESS, "2"}) + @IR(counts = {IRNode.FIELD_ACCESS, "4"}) @ExpectedFailure(ruleId = 5, phase = CompilePhase.PRINT_OPTO_ASSEMBLY, counts = 1) public Object defaultOnBoth(Helper h) { i = 34;
28-03-2025
Failure[methodName=defaultOnBoth, irRuleId=3, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2] refers to: @IR(counts = {IRNode.STORE, "20", IRNode.FIELD_ACCESS, "2", IRNode.COUNTED_LOOP, "2"}) @ExpectedFailure(ruleId = 3, phase = CompilePhase.PRINT_IDEAL, counts = {1, 3}) @ExpectedFailure(ruleId = 3, phase = CompilePhase.PRINT_OPTO_ASSEMBLY, counts = 2) ... public Object defaultOnBoth(Helper h) { i = 34; l = 34; return h.getString(); } This entry is found in the "expected failures but was not observed" list. That means, we expected that the 2nd constraint of "counts", i.e. IRNode.FIELD_ACCESS, "2", failed but it did not. On the other hand, in the "found failures but not expected list", we find this entry: Failure[methodName=defaultOnBoth, irRuleId=1, compilePhase=PRINT_OPTO_ASSEMBLY, checkAttributeType=COUNTS, constraintId=2] corresponding to this IR rule: @IR(failOn = {IRNode.STORE, IRNode.FIELD_ACCESS, IRNode.COUNTED_LOOP}, counts = {IRNode.STORE, "20", IRNode.FIELD_ACCESS, "3", IRNode.COUNTED_LOOP, "2"}) @ExpectedFailure(ruleId = 1, phase = CompilePhase.PRINT_OPTO_ASSEMBLY, failOn = 2) @ExpectedFailure(ruleId = 1, phase = CompilePhase.PRINT_IDEAL, failOn = 1, counts = {1, 3}) So, we found the 2nd constraint of the "counts" rule, i.e. IRNode.FIELD_ACCESS, "3", to fail which was not expected. I conclude from that, that on the Oracle supported platforms, we find the FIELD_ACCESS regex 3x while we find it 2x on PPC for the method defaultOnBoth(). A similar mismatch seems to happen for the defaultOnOptoAssembly() method. To fix this, I suggest the following: Choose a constraint that is guaranteed to fail and work. This means we should update those constraints mentioned in @ExpectedFailure, i.e. the ones that should fail, to something like "FIELD_ACCESS = 10" (definitely failing) and the ones not mentioned in @ExpectedFailure, i.e. the ones that should work, to something that is guaranteed to work as for example "FIELD_ACCESS < 10". [~mdoerr] Maybe you can try this out on a PPC machine.
28-03-2025
Okay, [~chagedorn] any idea?
28-03-2025
No, JDK-8352595 is already included, but the error shows up.
28-03-2025
Isn't this a duplicate of JDK-8352595?
28-03-2025
[~thartmann] How can we find out what exactly fails?
27-03-2025