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

[Richard Biener <rguenther at suse dot de>]

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 ;)

Richard.