From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-477688-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18796 invoked by alias); 18 Feb 2015 15:25:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 18450 invoked by uid 48); 18 Feb 2015 15:25:43 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs
Date: Wed, 18 Feb 2015 15:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62630-4-Kn5xRv2H29@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62630-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62630-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg02021.txt.bz2

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