RFR: 8257813: [redo] C2: Filter type in PhiNode::Value() for induction variables of trip-counted integer loops

[Roland Westrelin]

I looked at why 8250607 (C2: Filter type in PhiNode::Value() for induction variables of trip-counted integer loops) causes
auto-vectorization to fail sometimes and AFAICT, detection of reductions fails because with 8250607 the shape of the loop body is slightly different. So 8250607 reveals an underlying limitation. In SuperWord::reduction() the test that checks for depths in the dependency graph is too strict. In a chain of reduction operations, s2 is not guaranteed to be a depth of s1 + 1 because it may depend on an operation other than s1. I think that test should be depth(s2) > depth(s1).

What I'm observing for the case where vectorization fails is:

`1142  OrI  === _  1170  1143  [[ 1130 ]]  !orig=983,324,897 !jvms: RedTest_int::orReductionImplement @ bci:52 (line 181)
`
at depth 11

that depends on

`1170  OrI  === _  1207  1171  [[ 1142 ]]  !orig=1003,858,324,897 !jvms: RedTest_int::orReductionImplement @ bci:52 (line 181)`

at depth 9 and:

`1143  AddI  === _  1144  1150  [[ 1139  1142 ]]  !orig=984,268,[323] !jvms: RedTest_int::orReductionImplement @ bci:44 (line 180)`

at depth 10.

In SuperWord::reduction(), s1 = 1170 and s2 = 1142.

If now I disable the change in PhiNode::Value() and the reduction is correctly detected, 1142 is at depth 11 and 1170 at depth 10. 1170 is at depth 10 (instead of 9) because the dependency graph includes a CastII that is optimized out with the change in PhiNode::Value() .

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

Commit messages:
 - reduction + iv phi

Changes: https://git.openjdk.java.net/jdk/pull/1658/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1658&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257813
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1658.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1658/head:pull/1658

PR: https://git.openjdk.java.net/jdk/pull/1658