https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 19 Oct 2017, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604 > > --- Comment #2 from amker at gcc dot gnu.org --- > (In reply to Richard Biener from comment #1) > > I suppose loop distribution inserted a version copy turning this into a > > non-perfect nest for outer loops and thus disabling autopar there. > > > > What probably makes sense is to run autoparallelization earlier or to try > Given passes like split/distribution/interchange are not to help > GRAPHITE/autopar, another choice is to push them later after GRAPHITE and > autopar? I suppose sometimes they will help autopar given w/o the help of GRAPHITE autopar can only handle perfect nests. I think it would be nice to rewrite autopar in terms of GRAPHITE only, thus instruct ISL to tile the parallel loops in the region so the outermost parallel loops in a SCOP can be OMP-ized by the code generator if requested (that's similar to the idea of tiling the inner loop for autovectorizing). But yes, if autopar weren't restricted we'd move it before all high-level loop opts. And we'd have a split pipeline between a graphite pass and our own high-level loop opts if graphite were good enough.
