From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-402100-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 16475 invoked by alias); 27 Sep 2012 10:43:18 -0000
Received: (qmail 16425 invoked by uid 48); 27 Sep 2012 10:43:01 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test "rnflow" degraded
Date: Thu, 27 Sep 2012 10:43: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-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-54717-4-aYBtp9xCAT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54717-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54717-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
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
X-SW-Source: 2012-09/txt/msg02266.txt.bz2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-27 10:43:00 UTC ---
I can reproduce the slowdown.  Code differences appear first in early FRE,
good ones like:

-  _84 = &*a_56(D)[_83];
+  _84 = _75;

which was the intention of the patch (and that is also likely the
reason for the inliner code size/time estimate changes).

It would be nice to get a smaller testcase for the PRE change you quote.

Unfortunately the big slowdown does not reproduce with -fno-inline which makes
it harder to track down.

The real differences do appear in PRE, some of the kind you quote and
some where we perform more PRE like:

@@ -19695,11 +19720,13 @@
   <bb 289>:
   pretmp_ = stride.258_ * _;
   pretmp_ = offset.259_ + pretmp_;
+  pretmp_ = stride.258_ * _;
+  pretmp_ = offset.259_ + pretmp_;

   <bb 123>:
   # i_ = PHI <1(289), i_(292)>
-  _ = stride.258_ * _;
-  _ = _ + offset.259_;
+  _ = pretmp_;
+  _ = pretmp_;

Aside from that the differences you quote result in less if-conversion
applied:

   # ival2_ = PHI <ival2_(39), ival2_(41)>
   # ival2_ = PHI <ival2_(39), ival2_(41)>
-  # prephitmp_ = PHI <pretmp_(39), prephitmp_(41)>
   _ = (integer(kind=8)) ival2_;
   _ = _ + -1;
   _ = *xxtrt_(D)[_];
-  ival2_ = _ < prephitmp_ ? ival2_ : ival2_;
-  prephitmp_ = MIN_EXPR <_, prephitmp_>;
+  _ = (integer(kind=8)) ival2_;
+  _ = _ + -1;
+  _ = *xxtrt_(D)[_];
+  ival2_ = _ < _ ? ival2_ : ival2_;

but that does not result in any extra or missed vectorization.

Btw, dropping to -O2 also fixes the regression.

So, it's not at all clear what we are chasing here (the PRE seems to be
a partial antic expression).