On Wed, Apr 10, 2019 at 7:48 AM bin.cheng <bin.ch...@linux.alibaba.com> wrote:
>
> Hi,
> This patch fixes ICE reported by PR90021. The issue has been there since
> loop interchange
> and recently exposed by patch for PR89725. As PR comment suggests, we have
> equal access
> function {{1, +, 1}_6, +, 1}_4 and _6 is of loop_nest's outer loop. This
> patch introduces
> new parameter loopnum to function evolution_function_is_univariate_p so that
> the above
> scev won't be considered as multivariate, i.e, {1, +, 1}_6 is considered as a
> symbol to the
> loop_nest. Note we only change computation of classic dist vector, rather
> than DDR itself.
>
> Bootstrap and test on x86_64. Is it ok?
OK.
> BTW, I wonder if collecting data reference in one loop but computing DDR in
> an inner loop
> is useful in the future, besides loop interchange.
I guess it's useful for compile-time but eventually we can also
refactor the data-ref code
to be able to initialize a new data-ref from an already existing one,
re-analyzing it for
an outer loop. Not sure if that's cheaper in any ways though.
Eventually the caching
done by SCEV can also be improved.
That said, we re-used the data-refs to avoid doing a quadratic amount
of analyses
during the search of the loop pair to interchange in a deep nest - I
think that's
very much desirable also for other passes operating on deeper nests of which
we have none at the moment - loop distribution being the closest candidate.
I think graphite also suffers from this somewhat in its SCOP finding/analysis.
Richard.
> Thanks,
> bin
>
> 2019-04-10 Bin Cheng <bin.ch...@linux.alibaba.com>
>
> PR tree-optimization/92001
> * tree-chrec.c (evolution_function_is_univariate_p): New parameter
> and check univariate against it.
> * tree-chrec.h (evolution_function_is_univariate_p): New parameter.
> * tree-data-ref.c (add_other_self_distances): Pass new argument.
>
> 2018-04-10 Bin Cheng <bin.ch...@linux.alibaba.com>
>
> PR tree-optimization/92001
> * gcc/testsuite/gfortran.dg/pr90021.f90: New test.
