Re: [patch,openacc] Propagate independent clause for OpenACC kernels pass

[Julian Brown <julian at codesourcery dot com>]

On Tue, 4 Dec 2018 14:55:03 +0100
Richard Biener <rguenther@suse.de> wrote:

> On Tue, 4 Dec 2018, Jakub Jelinek wrote:
> 
> > On Mon, Dec 03, 2018 at 11:40:39PM +0000, Julian Brown wrote:  
> > > Jakub asked in the following email at the time of the patch
> > > submission for the gomp4 branch what the difference was between
> > > the new marked_independent flag and safelen == INT_MAX:
> > > 
> > >   https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01100.html
> > > 
> > > If I understand the followup correctly,
> > > 
> > >   https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01117.html
> > > 
> > > a setting of safelen > 1 means that up to that number of loop
> > > iterations can run together in lockstep (as if each insn in the
> > > loop was blindly rewritten to a safelen-width SIMD equivalent) --
> > > but anything that happens in iteration N + 1 cannot happen before
> > > something that happens in iteration N. Chung-Lin pointed out that
> > > OpenACC's semantics are even less strict (allowing iterations to
> > > proceed fully independently in an arbitrary order), so the
> > > marked_independent flag does carry non-redundant information --
> > > even with safelen set to INT_MAX.  
> > 
> > OpenMP 5 (not implemented in GCC 9 though) has order(concurrent)
> > clause for this (no cross-iteration dependencies at all, iterations
> > can be run in any order, in parallel etc.).
> > 
> > I believe it matches the can_be_parallel flag we now have, but I
> > remember there were some issues with that flag for use in DO
> > CONCURRENT.
> > 
> > Or do we want to have some other flag for really independent
> > iterations? What passes could use that?  Would the vectorizer
> > appreciate the stronger assertion in some cases?  
> 
> The vectorizer doesn't really care.  It would be autopar that should.
> The issue with using can_be_parallel for DO CONCURRENT was that the
> middle-end introduces non-trivial sharing between iterations,
> introducing dependences that then make the loop no longer
> can_be_parallel.  I believe similar things could happen with
> ->safelen (consider loop reversal and existing forward dependences).
> I guess we're simply lucky in that area ;)

I wondered if I should try modifying the patch to set the
can_be_parallel flag for kernels loops with an "independent" clause
instead (and try to address Jakub's other comments). Do I understand
right that the issue with the can_be_parallel flag is that it does not
necessarily guarantee safety of optimisations for loops which are
supposed to have fully-independent iterations, rather than that it has
different semantics from the proposed marked_independent flag?

However, it turns out that this patch has a dependency on this one:

  https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01179.html

and, according to Cesar, that in turn has a dependency on another patch:

  https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01189.html

so, it might take me a little time to untangle all that. Does the rough
idea sound plausible, though? Or is modifying this patch to use
can_be_parallel likely to just cause problems at present?

Thanks,

Julian