https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 29 Apr 2016, ienkovich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729 > > --- Comment #14 from Ilya Enkovich <ienkovich at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #13) > > (In reply to Yuri Rumyantsev from comment #12) > > > Created attachment 38367 [details] > > > modified patch > > > > The loop->aux flagging looks redundant to me. Why is ->safelen only valid > > before vectorization? I suppose we're lucky that no pass before > > vectorization > > applies any unrolling (like predictive commoning for example) as such pass > > must adjust ->safelen accordingly. But as LIM only cares for safelen > 0 > > _this_ property shouldn't change, not even by vectorization, no? > > > > SIMD lane access is not invariant before vectorization but is invariant after > vectorization. This means when GOMP_SIMD_LANE calls are removed we can't use > safelen for invariant moves anymore. Ah, I see. So the vectorizer needs to clear ->safelen then if safelen doesn't apply to simduid. Richard.
