[PATCH][GRAPHITE] Fix PR82449

[Richard Biener]

On Fri, 6 Oct 2017, Sebastian Pop wrote:

> On Fri, Oct 6, 2017 at 6:56 AM, Richard Biener <rguenther@suse.de> wrote:
> 
> >
> > The following fences off a few more SCEVs through scev_analyzable_p given
> > at the end we need those pass chrec_apply when getting a rename through
> > SCEV.
> >
> > The SCEV in question is
> >
> >   {(integer(kind=4)) {0, +, {1, +, 1}_1}_1, + 1}_2
> >
> > which fails to chrec_apply in the CHREC_LEFT part because that part
> > is not affine (and we're usually not replacing a IV with a constant
> > where chrec_apply might handle one or the other case).
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > This fixes three out of the remaining 8 codegen errors in SPEC CPU 2006.
> >
> > Ok?
> >
> > Thanks,
> > Richard.
> >
> > 2017-10-06  Richard Biener  <rguenther@suse.de>
> >
> >         PR tree-optimization/82449
> >         * sese.c (can_chrec_apply): New function.
> >         (scev_analyzable_p): Check we can call chrec_apply on the SCEV.
> >
> >         * gfortran.dg/graphite/pr82449.f: New testcase.
> >
> > Index: gcc/sese.c
> > ===================================================================
> > --- gcc/sese.c  (revision 253477)
> > +++ gcc/sese.c  (working copy)
> > @@ -421,6 +421,27 @@ invariant_in_sese_p_rec (tree t, const s
> >    return true;
> >  }
> >
> > +/* Check whether we can call chrec_apply on CHREC with arbitrary X and
> > VAR.  */
> > +
> > +static bool
> > +can_chrec_apply (tree chrec)
> > +{
> > +  if (automatically_generated_chrec_p (chrec))
> > +    return false;
> > +  switch (TREE_CODE (chrec))
> > +    {
> > +    case POLYNOMIAL_CHREC:
> > +      if (evolution_function_is_affine_p (chrec))
> > +       return (can_chrec_apply (CHREC_LEFT (chrec))
> > +               && can_chrec_apply (CHREC_RIGHT (chrec)));
> > +      return false;
> > +    CASE_CONVERT:
> > +      return can_chrec_apply (TREE_OPERAND (chrec, 0));
> > +    default:;
> > +      return tree_does_not_contain_chrecs (chrec);
> > +    }
> > +}
> > +
> >  /* Return true when DEF can be analyzed in REGION by the scalar
> >     evolution analyzer.  */
> >
> > @@ -449,6 +470,7 @@ scev_analyzable_p (tree def, sese_l &reg
> >         || !defined_in_sese_p (scev, region))
> >      && (tree_does_not_contain_chrecs (scev)
> >         || evolution_function_is_affine_p (scev))
> >
> 
> Why isn't evolution_function_is_affine_p returning false on {0, +, {1, +,
> 1}_1}_1?
> This is quadratic.

It returns false on that but the CHREC we ask it on is

{(integer(kind=4)) {0, +, {1, +, 1}_1}_1, + 1}_2

only the initial value is "quadratic".

Richard.