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

[Roland Westrelin]

On Mon, 7 Dec 2020 11:54:52 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> 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() .
>
> That's reasonable. Looks good to me!

@chhagedorn @vnkozlov thanks for the reviews

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

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