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).