https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87917
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Sebastian Pop from comment #3) > > Sebastian - can you say if > > evolution_function_is_affine_multivariate_p ({0, +, {0, +, 4}_1}_2, 1) > > should really return true? > > You are right, {0, +, {0, +, 4}_1}_2 is not a valid affine multivariate > function: only the base (not the step) should vary in an outer loop. > > For example, this would be an affine multivariate: {{0, +, 4}_1, +, 42}_2. Hmm, but evolution_function_is_affine_multivariate_p currently says: switch (TREE_CODE (chrec)) { case POLYNOMIAL_CHREC: if (evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec), loopnum)) { if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec), loopnum)) return true; so for {0, +, {0, +, 1}_1 }_2 and asking for loopnum == 2 where loop 2 is nested inside loop 1 this would already return true because {0, +, 1}_1 is invariant in 2. Now for the testcase we are asking for loopnum == 1 where the above doesn't hold but we then fall through to else { if (TREE_CODE (CHREC_RIGHT (chrec)) == POLYNOMIAL_CHREC && CHREC_VARIABLE (CHREC_RIGHT (chrec)) != CHREC_VARIABLE (chrec) && evolution_function_is_affine_multivariate_p (CHREC_RIGHT (chrec), loopnum)) return true; which surely looks bogus (the != should probably be a flow_loop_nested_p in some way). A SCEV like {0, +, {0, +, 1}_1 }_1 isn't valid anyways. If trying to make sense of evolution_function_is_affine_multivariate_p by looking at evolution_function_is_affine_p and evolution_function_is_univariate_p I would come up with sth like if (evolution_function_is_invariant_p (CHREC_RIGHT (chrec), CHREC_VARIABLE (chrec)) && (TREE_CODE (CHREC_RIGHT (chrec)) != POLYNOMIAL_CHREC || evolution_function_is_affine_multivariate_p (CHREC_RIGHT (chrec))) return true; else return false; That is, why's the evolution of CHREC_LEFT restricted at all here? That said - this would also make the loopnum argument to evolution_function_is_affine_multivariate_p moot. So like the following together with removing the arg everywhere. It doesn't fix the ICE though since we then implicitely ask for loopnum == 2. Index: tree-chrec.c =================================================================== --- tree-chrec.c (revision 266145) +++ tree-chrec.c (working copy) @@ -1063,7 +1063,7 @@ evolution_function_is_invariant_p (tree evolution. */ bool -evolution_function_is_affine_multivariate_p (const_tree chrec, int loopnum) +evolution_function_is_affine_multivariate_p (const_tree chrec) { if (chrec == NULL_TREE) return false; @@ -1071,33 +1071,11 @@ evolution_function_is_affine_multivariat switch (TREE_CODE (chrec)) { case POLYNOMIAL_CHREC: - if (evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec), loopnum)) - { - if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec), loopnum)) - return true; - else - { - if (TREE_CODE (CHREC_RIGHT (chrec)) == POLYNOMIAL_CHREC - && CHREC_VARIABLE (CHREC_RIGHT (chrec)) - != CHREC_VARIABLE (chrec) - && evolution_function_is_affine_multivariate_p - (CHREC_RIGHT (chrec), loopnum)) - return true; - else - return false; - } - } - else - { - if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec), loopnum) - && TREE_CODE (CHREC_LEFT (chrec)) == POLYNOMIAL_CHREC - && CHREC_VARIABLE (CHREC_LEFT (chrec)) != CHREC_VARIABLE (chrec) - && evolution_function_is_affine_multivariate_p - (CHREC_LEFT (chrec), loopnum)) - return true; - else - return false; - } + return (evolution_function_is_invariant_p (CHREC_RIGHT (chrec), + CHREC_VARIABLE (chrec)) + && (TREE_CODE (CHREC_RIGHT (chrec)) != POLYNOMIAL_CHREC + || evolution_function_is_affine_multivariate_p + (CHREC_RIGHT (chrec)))); default: return false; Hmm, maybe what is missing is a check at the top whether the CHREC itself varies in loopnum? Anyway, the current code doesn't make much sense to me. And what dependence analysis does - asking for dependence of two DRs in loop 2 (the inner one) with respect to evolution in the outer loop doesn't make much sense? In any case analyze_subscript_affine_affine doesn't seem to handle the case of an tree_contains_chrecs (CHREC_RIGHT (..)) because initialize_matrix_A expects it to be an INTEGER_CST (even! not just invariant, but that is checked for). The other caller of analyze_subscript_affine_affine (analyze_siv_subscript) seems to use evolution_function_is_affine_in_loop and help themselves with can_use_analyze_subscript_affine_affine to handle some cases of chrec_contains_symbols. So I am now testing the simple Index: gcc/tree-data-ref.c =================================================================== --- gcc/tree-data-ref.c (revision 266145) +++ gcc/tree-data-ref.c (working copy) @@ -3994,9 +3993,9 @@ analyze_miv_subscript (tree chrec_a, dependence_stats.num_miv_independent++; } - else if (evolution_function_is_affine_multivariate_p (chrec_a, loop_nest->num) + else if (evolution_function_is_affine_in_loop (chrec_a, loop_nest->num) && !chrec_contains_symbols (chrec_a) - && evolution_function_is_affine_multivariate_p (chrec_b, loop_nest->num) + && evolution_function_is_affine_in_loop (chrec_b, loop_nest->num) && !chrec_contains_symbols (chrec_b)) { /* testsuite/.../ssa-chrec-35.c but still somehow is_affine_multivariate returns true for something that is_affine_in_loop does not ... (so the predicates look inconsistent). Any help appreciated.