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

[Richard Biener <rguenther at suse dot de>]

On Wed, 5 Dec 2018, Julian Brown wrote:

> 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?

For Fortran DO CONCURRENT it caused problems.  can_be_parallel causes
auto-parallelization to omit all dependence checking which works
fine for the small time this flag is usually set by the graphite
dependence analysis (which marks loops that way) and autopar itself
(which is also the only consumer of the flag right now).  But if
the frontend already sets the flag there's too much chance for the
middle-end to mess up dependences and thus the autopar code would
need to double-check (also making the flag somewhat useless).

Richard.

> Thanks,
> 
> Julian
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)