[PATCH 0/4] openacc: Async fixes

[Julian Brown]

On Wed, 30 Jun 2021 10:28:00 +0200
Thomas Schwinge <thomas@codesourcery.com> wrote:

> >  - The OpenACC profiling-interface implementation did not measure
> >    asynchronous operations properly.  
> 
> We'll need to be careful: (possibly, an older version of) that one we
> internally had identified to be causing some issues; see the
> "acc_prof-parallel-1.c intermittent failure on og10 branch" emails,
> 2020-07.

Hmm, I'll check those.

> >  - Several test cases misuse OpenACC asynchronous support (more race
> >    conditions).  
> 
> Mostly ACK, but some more changes may be necessary; please see
> <http://mid.mail-archive.com/87sg1s9s9l.fsf@euler.schwinge.homeip.net>
> (you were CCed).

Thanks -- these test changes have been floating around uncommitted for
too long already, I guess...

> >  .../libgomp.oacc-c-c++-common/deep-copy-10.c  |  14 +-  
> 
> Please provide some detail about that one ("Fix async behaviour").
> It's not obvious to me what's wrong with the current version (but I
> haven't really spent time on that yet).

Aha, well I didn't see what was wrong with it either when I wrote the
test!

The problem is that we have copyin/modify-on-target/copyout operations
that process the *same data* from different async streams on successive
loop iterations. Those async streams are independent from one another,
so depending on how they are scheduled, we can be copying-in on one
async stream whilst simultaneously copying-out on another async stream
-- so of course, the data gets corrupted.

So the fix makes sure that each async stream only operates on "its own"
data. The increase in number of loop iterations was specifically to
tickle the flaw in the workaround used for GCN wrt. the ephemeral
copies -- i.e. snapshotting all host data immediately.

HTH,

Julian