https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, expand_simple_operations will not expand the MIN/MAX_EXPRs. If we change
that the patch makes data-ref analysis fail differently (we correctly can
then compute bounds for the loops!), as we still may wrap with
(int) {(unsigned int) graphite_IV.5_50, +, 1}_3;
(non-zero initial value) even with an niter bound of 2147483646.
That said, the loop conditions and guards are set up in a funny enough way
to confuse GCC ...
Index: gcc/tree-ssa-loop-niter.c
===================================================================
--- gcc/tree-ssa-loop-niter.c (revision 220784)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -1674,6 +1687,12 @@ expand_simple_operations (tree expr, tre
ee = expand_simple_operations (e, stop);
return fold_build2 (code, TREE_TYPE (expr), ee, e1);
+ case MIN_EXPR:
+ case MAX_EXPR:
+ e1 = expand_simple_operations (gimple_assign_rhs1 (stmt));
+ ee = expand_simple_operations (gimple_assign_rhs2 (stmt));
+ return fold_build2 (code, TREE_TYPE (expr), e1, ee);
+
default:
return expr;
}
(not a good idea I think)
The match.pd pattern:
Index: gcc/match.pd
===================================================================
--- gcc/match.pd (revision 220784)
+++ gcc/match.pd (working copy)
@@ -567,6 +567,18 @@ (define_operator_list inverted_tcc_compa
&& operand_equal_p (@1, TYPE_MAX_VALUE (type), OEP_ONLY_CONST))
@1))
+/* We can remove extensions of min/max operands and shorten the operation. */
+(for minmax (min max)
+ (simplify
+ (minmax (convert @0) (convert? @1))
+ (if (INTEGRAL_TYPE_P (type)
+ && TYPE_PRECISION (TREE_TYPE (@0)) < TYPE_PRECISION (type)
+ && (((GENERIC && TYPE_MAIN_VARIANT (TREE_TYPE (@0)) ==
TYPE_MAIN_VARIANT (TREE_TYPE (@1)))
+ || (GIMPLE && types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1))))
+ || (TREE_CODE (@1) == INTEGER_CST
+ && int_fits_type_p (@1, TREE_TYPE (@0))))
+ && TYPE_PRECISION (TREE_TYPE (@0)) == GET_MODE_PRECISION (TYPE_MODE
(TREE_TYPE (@0))))
+ (convert (minmax @0 (convert @1))))))
should probably be restricted to apply when feeding another conversion
or a comparison (all shorten_* operations are probably profitable when
feeding comparisons as well).
