On Tue, 4 Dec 2018 14:55:03 +0100 Richard Biener <rguent...@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
