-
Bug
-
Resolution: Fixed
-
P3
-
11, 17
-
b08
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8294714 | 11.0.18-oracle | Tobias Hartmann | P3 | Resolved | Fixed | b02 |
Currently, GCM considers it legal to move stores into inner loops, and relies on the frequency-based heuristic in PhaseCFG::hoist_to_cheaper_block() to prevents such movements from happening.
Moving a store into an inner loop should be however seen as illegal, as it breaks the invariant that, after GCM, memory definitions should not interfere. For example:
Original placement of store in B1 (loop L1):
B1 (L1):
m1 <- ..
m2 <- store m1, ..
B2 (L2):
jump B2
B3 (L1):
.. <- .. m2, ..
Wrong "hoisting" of store to B2 (in loop L2, child of L1):
B1 (L1):
m1 <- ..
B2 (L2):
m2 <- store m1, ..
# Wrong: m1 and m2 interfere at this point.
jump B2
B3 (L1):
.. <- .. m2, ..
Currently, such illegal movements are prevented by pinning stores to their original block, if the CFG is irreducible; and by the properties of the frequency estimation heuristic, if the CFG is reducible. This RFE proposes discarding the illegal movements beforehand, so that decisions that affect correctness are not left to the heuristic's discretion. More specifically, stores and other memory-defining nodes should not be allowed to move into deeper loops than the ones they originally belong to.
The method testReducible() in test/hotspot/jtreg/compiler/codegen/TestGCMStorePlacement.java illustrates the issue: GCM considers moving counter++ into the loop, and only the frequency estimation heuristic prevents it from happening.
Moving a store into an inner loop should be however seen as illegal, as it breaks the invariant that, after GCM, memory definitions should not interfere. For example:
Original placement of store in B1 (loop L1):
B1 (L1):
m1 <- ..
m2 <- store m1, ..
B2 (L2):
jump B2
B3 (L1):
.. <- .. m2, ..
Wrong "hoisting" of store to B2 (in loop L2, child of L1):
B1 (L1):
m1 <- ..
B2 (L2):
m2 <- store m1, ..
# Wrong: m1 and m2 interfere at this point.
jump B2
B3 (L1):
.. <- .. m2, ..
Currently, such illegal movements are prevented by pinning stores to their original block, if the CFG is irreducible; and by the properties of the frequency estimation heuristic, if the CFG is reducible. This RFE proposes discarding the illegal movements beforehand, so that decisions that affect correctness are not left to the heuristic's discretion. More specifically, stores and other memory-defining nodes should not be allowed to move into deeper loops than the ones they originally belong to.
The method testReducible() in test/hotspot/jtreg/compiler/codegen/TestGCMStorePlacement.java illustrates the issue: GCM considers moving counter++ into the loop, and only the frequency estimation heuristic prevents it from happening.
- backported by
-
JDK-8294714 C2: Forbid GCM to move stores into loops
-
- Resolved
-
- blocks
-
JDK-8257146 C2: extend the scope of StressGCM
-
- Closed
-
- duplicates
-
JDK-8288975 Incorrect result with C2 compiled code
-
- Closed
-
- relates to
-
JDK-8349930 C2: verify memory liveness invariants after scheduling
-
- In Progress
-
-
JDK-8255763 C2: OSR miscompilation caused by invalid memory instruction placement
-
- Resolved
-
(3 links to)