This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][Graphite]
On Mon, 9 Jan 2012, Tobias Grosser wrote:
> On 01/09/2012 04:34 PM, Richard Guenther wrote:
> >
> > This fixes the 2nd P1 ICE.
> >
> > There is a disconnect on how we analyze data-references during SCOP
> > detection
> > (outermost_loop is the root of the loop tree) and during SESE-to-poly
> > where
> > outermost is determined by outermost_loop_in_sese_1 (). That influences
> > the SCEV result and thus we do not break the SCOP at a stmt we have to
> > break
> > it.
> >
> > The following patch fixes this using a sledgehammer - require the
> > data-ref to be representable if analyzed with respect to all loops
> > it can nest in.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> >
> > Ok?
>
> This one looks good to me. The new region based scop detection should fix this
> issue, but until we can get the relevant patches in, this looks like a good
> fix. Thanks for fixing the graphite PRs.
Btw, the patch requires me to XFAIL the following tests:
FAIL: gcc.dg/graphite/scop-20.c scan-tree-dump-times graphite "number of
SCoPs: 2" 1
huh, we now only detect one SCoP (I suppose not all stmts of a
function will end up in SCoPs? So we have an unhandled loop here
now.)
FAIL: gfortran.dg/graphite/interchange-1.f -O scan-tree-dump-times
graphite "will be interchanged" 1
No SCoPs detected anymore.
FAIL: gfortran.dg/graphite/block-1.f90 -O scan-tree-dump-times graphite
"number of SCoPs: 1" 1
Likewise.
FAIL: gfortran.dg/graphite/block-2.f -O scan-tree-dump-times graphite
"number of SCoPs: 2" 1
Likewise.
But I also saw no easy way to use the "proper" outermost loop during
the analysis phase, so we have to live with this for 4.7 I believe.
Thus, applied.
Thanks,
Richard.