This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch,openacc] Propagate independent clause for OpenACC kernels pass
- From: Julian Brown <julian at codesourcery dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Cesar Philippidis <cesar at codesourcery dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Chung-Lin Tang <cltang at codesourcery dot com>
- Date: Wed, 5 Dec 2018 23:37:38 +0000
- Subject: Re: [patch,openacc] Propagate independent clause for OpenACC kernels pass
- References: <f432a0c0-63c2-044f-846b-f049d1214882@codesourcery.com> <20181203234039.12f8b8fa@squid.athome> <20181204134526.GR12380@tucnak> <alpine.LSU.2.20.1812041452300.1827@zhemvz.fhfr.qr>
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