RFR: 8301489: ShortLoopOptimizer might lift instructions before their inputs

[Roberto Castañeda Lozano]

On Thu, 15 Jun 2023 11:13:02 GMT, Daniel Skantz <duke at openjdk.org> wrote:

> ShortLoopOptimizer might lift instructions before their inputs on some graph shapes. We propose adding a check that the insertion point for an instruction that is a candidate for hoisting should not be higher up the dominator tree than any inputs to the instruction.
> 
> Testing: tier1-tier3.
> 
> Additional testing: observed that `(cur_invariant && !v.is_valid())` never occurs on tier1-tier3 before the added test case.
> Also verified that the depth check is equivalent to `(*vp->block() == _insert->block()) || dominates(*vp, _insert)` on all of tier1-tier3.
> 
> Failure case: in the attached image the `arraylength` instruction from B10 is lifted to B0, as the dominator of B10 is calculated as B0. This is based on the logic in [`ComputeLinearScanOrder::compute_dominator_impl`](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_IR.cpp#L801).  But the array input is in Block 3. This is later spotted in `c1_LIRAssembler.cpp` with `Error: ShouldNotReachHere()`. We can reproduce the error on other instructions too -- the reader may refer to the test case provided.
> 
> ![image](https://github.com/openjdk/jdk/assets/111436254/9130516c-073d-45d1-a38a-af776e5e6672)

Good catch, analysis, and regression test Daniel. Great that you could generalize the fix to cover all other LICM cases. Just a couple of comments/suggestions.

src/hotspot/share/c1/c1_ValueMap.cpp line 362:

> 360: }
> 361: 
> 362: class CheckInsertionPoint: public ValueVisitor {

For consistency with other similar cases in `c1_ValueMap.cpp`: 
Suggestion:

class CheckInsertionPoint : public ValueVisitor {

src/hotspot/share/c1/c1_ValueMap.cpp line 421:

> 419:     // Check that insertion point has higher dom depth than all inputs to cur
> 420:     CheckInsertionPoint v(_insertion_point);
> 421:     cur->input_values_do(&v);

For compilation efficiency, would it be possible to perform this computation only when `cur_invariant` holds? You could for example encapsulate the creation of `v`, call to `cur->input_values_do(&v)`, and `v.is_valid()` check into an auxiliary function `is_dominated_by_inputs(_insertion_point, cur)` or similar and call that function below (`if (cur_invariant && is_dominated_by_inputs(_insertion_point, cur)) {`).

-------------

Changes requested by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14492#pullrequestreview-1485684935
PR Review Comment: https://git.openjdk.org/jdk/pull/14492#discussion_r1233707598
PR Review Comment: https://git.openjdk.org/jdk/pull/14492#discussion_r1233714992