On Thu, Jul 16, 2015 at 12:23 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Thu, Jul 16, 2015 at 12:19 PM, Thomas Schwinge > <tho...@codesourcery.com> wrote: >> Hi Tom! >> >> On Thu, 16 Jul 2015 10:46:00 +0200, Richard Biener >> <richard.guent...@gmail.com> wrote: >>> On Wed, Jul 15, 2015 at 10:26 PM, Tom de Vries <tom_devr...@mentor.com> >>> wrote: >>> > I tried to parallelize this fortran test-case (based on >>> > autopar/outer-1.c), >>> > [...] >> >>> > So I wondered, why not always use the graphite dependency analysis in >>> > parloops. (Of course you could use -floop-parallelize-all, but that also >>> > changes the heuristic). So I wrote a patch for parloops to use graphite >>> > dependency analysis by default (so without -floop-parallelize-all), but >>> > while testing found out that all the reduction test-cases started failing >>> > because the modifications graphite makes to the code messes up the >>> > parloops >>> > reduction analysis. >>> > >>> > Then I came up with this patch, which: >>> > - first runs a parloops pass, restricted to reduction loops only, >>> > - then runs graphite dependency analysis >>> > - followed by a normal parloops pass run. >>> > >>> > This way, we get to both: >>> > - compile the reduction testcases as before, and >>> > - profit from the better graphite dependency analysis otherwise. >> >>> graphite dependence analysis is too slow to be enabled unconditionally. >>> (read: hours in some simple cases - see bugzilla) >> >> Haha, "cool"! ;-) >> >> Maybe it is still reasonable to use graphite to analyze the code inside >> OpenACC kernels regions -- maybe such code can reasonably be expected to >> not have the properties that make its analysis lengthy? So, Tom, could >> you please identify and check such PRs, to get an understanding of what >> these properties are? > > Like the one in PR62113 or 53852 or 59121.
Btw, it would be nice to handle this case (or at least figure out why we can't) in GCCs dependence analysis. Richard. >> >> Grüße, >> Thomas
