From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-428796-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10985 invoked by alias); 2 Sep 2013 08:28:36 -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 10938 invoked by uid 48); 2 Sep 2013 08:28:32 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57511] [4.8/4.9 Regression] Missing SCEV final value replacement
Date: Mon, 02 Sep 2013 08:28: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: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57511-4-F2CYyGIojl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57511-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57511-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: 2013-09/txt/msg00036.txt.bz2

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> It looks like
> 
> Index: gcc/tree-scalar-evolution.c
> ===================================================================
> --- gcc/tree-scalar-evolution.c (revision 202068)
> +++ gcc/tree-scalar-evolution.c (working copy)
> @@ -2252,6 +2252,7 @@ instantiate_scev_name (basic_block insta
>    else if (res != chrec_dont_know)
>      {
>        if (inner_loop
> +         && def_bb->loop_father != inner_loop
>           && !flow_loop_nested_p (def_bb->loop_father, inner_loop))
>         /* ???  We could try to compute the overall effect of the loop here.
> */
>         res = chrec_dont_know;
> 
> should be correct, but it has some testsuite fallout that needs to be
> analyzed (at least uncovering an IVOPTS issue).

Ok, the only issue is gcc.dg/tree-ssa/reassoc-19.c FAILing because IVOPTs
now detects a BIV and does something - previously it bailed out.  We have

  <bb 2>:
  goto <bb 4>;

  <bb 3>:
  _7 = (sizetype) element_6(D);
  _8 = -_7;
  rite_9 = rite_1 + _8;
  bar (left_5(D), rite_9, element_6(D));

  <bb 4>:
  # rite_1 = PHI <rite_3(D)(2), rite_9(3)>
  if (left_5(D) <= rite_1)
    goto <bb 3>;
  else
    goto <bb 5>;

  <bb 5>:
  return;

and the BIV rite_1 is {rite_3(D), +, -(sizetype) element_6(D)}_1

that's good and an improvement.  IVOPTs decides to use the original BIV:

candidate 8 (important)
  var_before rite_1
  var_after rite_9
  original biv
  type char *
  base rite_3(D)
  step -(sizetype) element_6(D)
  base object (void *) rite_3(D)

which ideally would result in no code change ...?

Well.

The issue is that rewrite_use_nonlinear_expr of rite_9 = rite_1 + _8
gets things folded back to (char *) ((unsigned long) rite_1 - (unsigned long)
element_6(D)) from the more optimal
rite_1 + (-(sizetype) element_6(D))

Which is because of the way we try to get around plus vs. pointer-plus
in get_computation_aff and ultimately aff_combination_to_tree.

I'm going to clean that up ...