On Fri, Oct 6, 2017 at 6:56 AM, Richard Biener <rguent...@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  <rguent...@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.



> +    && can_chrec_apply (scev)
>      && (! loop
>         || ! loop_in_sese_p (loop, region)
>         || ! chrec_contains_symbols_defined_in_loop (scev, loop->num));
> Index: gcc/testsuite/gfortran.dg/graphite/pr82449.f
> ===================================================================
> --- gcc/testsuite/gfortran.dg/graphite/pr82449.f        (nonexistent)
> +++ gcc/testsuite/gfortran.dg/graphite/pr82449.f        (working copy)
> @@ -0,0 +1,11 @@
> +! { dg-do compile }
> +! { dg-options "-O2 -floop-nest-optimize" }
> +
> +      SUBROUTINE JDFIDX(MKL,KGSH)
> +      DIMENSION MKL(6,6)
> +      NKL=0
> +  400 DO 40 KG = 1,KGSH
> +      DO 40 LG = 1,KG
> +      NKL = NKL + 1
> +   40 MKL(LG,KG) = NKL
> +      END
>

Reply via email to