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:

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

Reply via email to