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.
