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