On Wed, 12 Nov 2014, Tom de Vries wrote: > On 12-11-14 15:17, Richard Biener wrote: > > On Wed, 12 Nov 2014, Tom de Vries wrote: > > > > > [ moved from gcc@ to gcc-patches@ ] > > > [ subject was: Re: [gomp4] openacc kernels directive support ] > > > On 30-09-14 15:37, Tom de Vries wrote: > > > > > I would be happily accepting splitting the current autopar pass > > > > > that way, that is, do > > > > > > > > > > NEXT_PASS (pass_parallelize_loops) > > > > > PUSH_INSERT_PASSES_WITHIN (pass_parallelize_loops) > > > > > NEXT_PASS (pass_expand_omp) > > > > > POP_INSERT_PASSES () > > > > > > > > > > and make the analysis code handle lowered OMP form. > > > > > > > > > > > > > To explore that, I created a tentative patch on top of the > > > > gomp-4_0-branch, > > > > which allows a non-bootstrap build and a gcc dg.exp run, so at least a > > > > couple of > > > > parloops test-cases. I can put this through bootstrap and reg-test if > > > > you > > > > confirm this patch is what you want. > > > > > > > > I'm not sure though OACC and autopar can share the actual function > > > > split-off. > > > > autopar is run rather late, later than the lto-stream point, while we > > > > need > > > > the > > > > split-off done before that for oacc. I'm also not sure what the point > > > > would > > > > be > > > > to have lowered OMP form in all those passes in between, I'd think you > > > > want > > > > to > > > > omp-expand it asap. > > > > > > Richard, > > > > > > This patch implements your proposal. It uses pass_expand_omp after > > > pass_parallelize_loops to expand the omp constructs inserted by > > > pass_parallelize_loops. > > > > > > Note: the patch doesn't remove omp_expand_local, since I'm still using > > > that in > > > my oacc kernels directive patch series. > > > > > > Bootstrapped and reg-tested on x86_64. > > > > > > OK for trunk? > > > > Hmm, we have used properties to communicate this kind of lowering > > need in the past. So I would prefer you introduce > > > > #define PROP_gimple_eomp (1 << 13) /* no OpenMP directives */ > > > > provide that property by the omp expansion pass, clear it from > > parloops and gate the omp expand pass if the property is already set. > > > > Look at how PROP_gimple_lcx is handled. > > > > Richard, > > I've followed up on your (and David's indentation) comment. > > The patch now defines a property PROP_gimple_eomp, and uses it to communicate > the need for expansion of omp constructs between passes. > > Bootstrapped and regtested on x86_64. > > OK for trunk?
Ok. Thanks, Richard.
