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

Christian Hagedorn chagedorn at openjdk.java.net
Mon Dec 7 11:57:12 UTC 2020


On Mon, 7 Dec 2020 08:10:46 GMT, Roland Westrelin <roland 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!

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

Marked as reviewed by chagedorn (Reviewer).

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


More information about the hotspot-compiler-dev mailing list