[patch,openacc] Propagate independent clause for OpenACC kernels pass
Richard Biener
rguenther@suse.de
Tue Dec 4 13:55:00 GMT 2018
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.
More information about the Gcc-patches
mailing list