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.
