This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Run pass_expand_omp_ssa after pass_paralellize_loops
- From: Richard Biener <rguenther at suse dot de>
- To: Tom de Vries <Tom_deVries at mentor dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Thomas Schwinge <Thomas_Schwinge at mentor dot com>, Bernd Schmidt <bernds at codesourcery dot com>, David Malcolm <dmalcolm at redhat dot com>
- Date: Thu, 13 Nov 2014 09:54:15 +0100 (CET)
- Subject: Re: Run pass_expand_omp_ssa after pass_paralellize_loops
- Authentication-results: sourceware.org; auth=none
- References: <53E24570 dot 1010200 at mentor dot com> <53F1EEB7 dot 1090509 at mentor dot com> <540ED665 dot 3010003 at mentor dot com> <alpine dot LSU dot 2 dot 11 dot 1409091243220 dot 20733 at zhemvz dot fhfr dot qr> <54185877 dot 6020902 at mentor dot com> <alpine dot LSU dot 2 dot 11 dot 1409221019590 dot 20733 at zhemvz dot fhfr dot qr> <542AB218 dot 5060502 at mentor dot com> <54635DA8 dot 6030603 at mentor dot com> <alpine dot LSU dot 2 dot 11 dot 1411121514180 dot 374 at zhemvz dot fhfr dot qr> <5463AAC6 dot 7070605 at mentor dot com>
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.