Re: [PATCH, 7/16] Add pass_dominator_oacc_kernels

[Tom de Vries]

On 11/11/15 12:05, Richard Biener wrote:

On Mon, 9 Nov 2015, Tom de Vries wrote:


On 09/11/15 16:35, Tom de Vries wrote:

Hi,

this patch series for stage1 trunk adds support to:
- parallelize oacc kernels regions using parloops, and
- map the loops onto the oacc gang dimension.

The patch series contains these patches:

   1Insert new exit block only when needed in
  transform_to_exit_first_loop_alt
   2Make create_parallel_loop return void
   3Ignore reduction clause on kernels directive
   4Implement -foffload-alias
   5Add in_oacc_kernels_region in struct loop
   6Add pass_oacc_kernels
   7Add pass_dominator_oacc_kernels
   8Add pass_ch_oacc_kernels
   9Add pass_parallelize_loops_oacc_kernels
  10Add pass_oacc_kernels pass group in passes.def
  11Update testcases after adding kernels pass group
  12Handle acc loop directive
  13Add c-c++-common/goacc/kernels-*.c
  14Add gfortran.dg/goacc/kernels-*.f95
  15Add libgomp.oacc-c-c++-common/kernels-*.c
  16Add libgomp.oacc-fortran/kernels-*.f95

The first 9 patches are more or less independent, but patches 10-16 are
intended to be committed at the same time.

Bootstrapped and reg-tested on x86_64.

Build and reg-tested with nvidia accelerator, in combination with a
patch that enables accelerator testing (which is submitted at
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01771.html ).

I'll post the individual patches in reply to this message.


this patch adds pass_dominator_oacc_kernels (which we may as well call
pass_dominator_no_peel_loop_headers. It doesn't do anything
oacc-kernels-specific), to be used in the kernels pass group.

The reason I'm adding a new pass instead of using pass_dominator is that
pass_dominator uses first_pass_instance. So adding a pass_dominator instance A
before a pass_dominator instance B has the unexpected consequence that it may
change the behaviour of instance B. I've filed PR68247 - "Remove
pass_first_instance" to note this issue.


This looks ok (minus my comments to patch #10)



AFAIU, if "Remove first_pass_instance from pass_dominator" get approved 
and committed, we can drop this patch, and use this pass instantiation 
instead in the oacc_kernels pass group:

...
  NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */);
...

Thanks,
- Tom

Re: [PATCH, 7/16] Add pass_dominator_oacc_kernels

[Richard Biener]

On Mon, 9 Nov 2015, Tom de Vries wrote:

> On 09/11/15 16:35, Tom de Vries wrote:
> > Hi,
> > 
> > this patch series for stage1 trunk adds support to:
> > - parallelize oacc kernels regions using parloops, and
> > - map the loops onto the oacc gang dimension.
> > 
> > The patch series contains these patches:
> > 
> >   1Insert new exit block only when needed in
> >  transform_to_exit_first_loop_alt
> >   2Make create_parallel_loop return void
> >   3Ignore reduction clause on kernels directive
> >   4Implement -foffload-alias
> >   5Add in_oacc_kernels_region in struct loop
> >   6Add pass_oacc_kernels
> >   7Add pass_dominator_oacc_kernels
> >   8Add pass_ch_oacc_kernels
> >   9Add pass_parallelize_loops_oacc_kernels
> >  10Add pass_oacc_kernels pass group in passes.def
> >  11Update testcases after adding kernels pass group
> >  12Handle acc loop directive
> >  13Add c-c++-common/goacc/kernels-*.c
> >  14Add gfortran.dg/goacc/kernels-*.f95
> >  15Add libgomp.oacc-c-c++-common/kernels-*.c
> >  16Add libgomp.oacc-fortran/kernels-*.f95
> > 
> > The first 9 patches are more or less independent, but patches 10-16 are
> > intended to be committed at the same time.
> > 
> > Bootstrapped and reg-tested on x86_64.
> > 
> > Build and reg-tested with nvidia accelerator, in combination with a
> > patch that enables accelerator testing (which is submitted at
> > https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01771.html ).
> > 
> > I'll post the individual patches in reply to this message.
> 
> this patch adds pass_dominator_oacc_kernels (which we may as well call
> pass_dominator_no_peel_loop_headers. It doesn't do anything
> oacc-kernels-specific), to be used in the kernels pass group.
> 
> The reason I'm adding a new pass instead of using pass_dominator is that
> pass_dominator uses first_pass_instance. So adding a pass_dominator instance A
> before a pass_dominator instance B has the unexpected consequence that it may
> change the behaviour of instance B. I've filed PR68247 - "Remove
> pass_first_instance" to note this issue.

This looks ok (minus my comments to patch #10)

Richard.

> Thanks,
> - Tom
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)