[Bug tree-optimization/57511] [4.8/4.9 Regression] Missing SCEV final value replacement

[rguenth at gcc dot gnu.org]

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