Wait at end of OpenACC asynchronous kernels regions

Message ID 87a6g0dk4h.fsf@euler.schwinge.homeip.net
State New
Headers show
Series
  • Wait at end of OpenACC asynchronous kernels regions
Related show

Commit Message

Thomas Schwinge Jan. 13, 2022, 10:07 a.m.
Hi!

On 2019-08-13T14:37:13-0700, Julian Brown <julian@codesourcery.com> wrote:
> This patch provides a workaround for unreliable operation of asynchronous

> kernels regions on AMD GCN. At present, kernels regions are decomposed

> into a series of parallel regions surrounded by a data region capturing

> the data-movement clauses needed by the region as a whole:

>

>   #pragma acc kernels async(n)

>   { ... }

>

> is translated to:


... simplified...

>   #pragma acc data copyin(...) copyout(...)

>   {

>     #pragma acc parallel async(n) present(...)

>     { ... }

>     #pragma acc parallel async(n) present(...)

>     { ... }

>   }

>

> This is however problematic for two reasons:

>

>  - Variables mapped by the data clause will be unmapped immediately at the end

>    of the data region, regardless of whether the inner asynchronous

>    parallels have completed. (This causes crashes for GCN.)

>

>  - Even if the "present" clause caused the reference count to stay above zero

>    at the end of the data region -- which it doesn't -- the "present"

>    clauses on the inner parallel regions would not cause "copyout"

>    variables to be transferred back to the host at the appropriate time,

>    i.e. when the async parallel region had completed.


> There is no "async" data construct in OpenACC


(Actually, as of OpenACC 3.2 there now is:
<https://gcc.gnu.org/PR97390> "[OpenACC] 'async' clause on 'data' construct"
-- but that's not yet implemented, so doesn't help us here.)

> so the correct solution

> (which I am deferring on for now) is probably to use asynchronous

> "enter data" and "exit data" directives when translating asynchronous

> kernels regions instead.


(Or rather, use structured 'data' (as we're now doing), but with
appropriate 'async' clauses.)

> The attached patch just adds a "wait" operation before the end of

> the enclosing data region. This works, but introduces undesirable

> synchronisation with the host.


ACK, thanks.  Pushed to master branch in
commit e52253bcc0916d9a7c7ba4bbe7501ae1ded3b8a8
"Wait at end of OpenACC asynchronous kernels regions", see attached.


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Patch

From e52253bcc0916d9a7c7ba4bbe7501ae1ded3b8a8 Mon Sep 17 00:00:00 2001
From: Julian Brown <julian@codesourcery.com>
Date: Fri, 9 Aug 2019 13:01:33 -0700
Subject: [PATCH] Wait at end of OpenACC asynchronous kernels regions

In OpenACC 'kernels' decomposition, we're improperly nesting synchronous and
asynchronous data and compute regions, giving rise to data races when the
asynchronicity is actually executed, as is visible in at least on test case
with GCN offloading.

The proper fix is to correctly use the asynchronous interfaces, making the
currently synchronous data regions fully asynchronous (see also
<https://gcc.gnu.org/PR97390> "[OpenACC] 'async' clause on 'data' construct",
which is to share the same implementation), but that's for later; for now add
some more synchronization.

	gcc/
	* omp-oacc-kernels-decompose.cc (add_wait): New function, split out
	of...
	(add_async_clauses_and_wait): ...here. Call new outlined function.
	(decompose_kernels_region_body): Add wait at the end of
	explicitly-asynchronous kernels regions.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/f-asyncwait-1.c: Remove GCN
	offloading execution XFAIL.

Co-Authored-By: Thomas Schwinge <thomas@codesourcery.com>
---
 gcc/omp-oacc-kernels-decompose.cc             | 31 ++++++++++++++-----
 .../libgomp.oacc-c-c++-common/f-asyncwait-1.c |  1 -
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/gcc/omp-oacc-kernels-decompose.cc b/gcc/omp-oacc-kernels-decompose.cc
index 4ca899d5ece..21872db3ed3 100644
--- a/gcc/omp-oacc-kernels-decompose.cc
+++ b/gcc/omp-oacc-kernels-decompose.cc
@@ -878,6 +878,18 @@  maybe_build_inner_data_region (location_t loc, gimple *body,
   return body;
 }
 
+static void
+add_wait (location_t loc, gimple_seq *region_body)
+{
+  /* A "#pragma acc wait" is just a call GOACC_wait (acc_async_sync, 0).  */
+  tree wait_fn = builtin_decl_explicit (BUILT_IN_GOACC_WAIT);
+  tree sync_arg = build_int_cst (integer_type_node, GOMP_ASYNC_SYNC);
+  gimple *wait_call = gimple_build_call (wait_fn, 2,
+					 sync_arg, integer_zero_node);
+  gimple_set_location (wait_call, loc);
+  gimple_seq_add_stmt (region_body, wait_call);
+}
+
 /* Helper function of decompose_kernels_region_body.  The statements in
    REGION_BODY are expected to be decomposed parts; add an 'async' clause to
    each.  Also add a 'wait' directive at the end of the sequence.  */
@@ -900,13 +912,7 @@  add_async_clauses_and_wait (location_t loc, gimple_seq *region_body)
       gimple_omp_target_set_clauses (as_a <gomp_target *> (stmt),
 				     target_clauses);
     }
-  /* A '#pragma acc wait' is just a call 'GOACC_wait (acc_async_sync, 0)'.  */
-  tree wait_fn = builtin_decl_explicit (BUILT_IN_GOACC_WAIT);
-  tree sync_arg = build_int_cst (integer_type_node, GOMP_ASYNC_SYNC);
-  gimple *wait_call = gimple_build_call (wait_fn, 2,
-					 sync_arg, integer_zero_node);
-  gimple_set_location (wait_call, loc);
-  gimple_seq_add_stmt (region_body, wait_call);
+  add_wait (loc, region_body);
 }
 
 /* Auxiliary analysis of the body of a kernels region, to determine for each
@@ -1352,6 +1358,17 @@  decompose_kernels_region_body (gimple *kernels_region, tree kernels_clauses)
      a wait directive at the end.  */
   if (async_clause == NULL)
     add_async_clauses_and_wait (loc, &region_body);
+  else
+    /* !!! If we have asynchronous parallel blocks inside a (synchronous) data
+       region, then target memory will get unmapped at the point the data
+       region ends, even if the inner asynchronous parallels have not yet
+       completed.  For kernels marked "async", we might want to use "enter data
+       async(...)" and "exit data async(...)" instead, or asynchronous data
+       regions (see also <https://gcc.gnu.org/PR97390>
+       "[OpenACC] 'async' clause on 'data' construct",
+       which is to share the same implementation).
+       For now, insert a (synchronous) wait at the end of the block.  */
+    add_wait (loc, &region_body);
 
   tree kernels_locals = gimple_bind_vars (as_a <gbind *> (kernels_body));
   gimple *body = gimple_build_bind (kernels_locals, region_body,
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/f-asyncwait-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/f-asyncwait-1.c
index f7ccecbf4b4..ef7735b2ef4 100644
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/f-asyncwait-1.c
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/f-asyncwait-1.c
@@ -3,7 +3,6 @@ 
 /* Based on '../libgomp.oacc-fortran/asyncwait-1.f90'.  */
 
 /* { dg-additional-options "--param=openacc-kernels=decompose" } */
-/* { dg-xfail-run-if TODO { openacc_radeon_accel_selected } } */
 
 /* { dg-additional-options "-fopt-info-all-omp" }
    { dg-additional-options "-foffload=-fopt-info-all-omp" } */
-- 
2.34.1