Richard Biener <richard.guent...@gmail.com> writes: > On Wed, Aug 29, 2018 at 11:10 AM Jakub Jelinek <ja...@redhat.com> wrote: >> >> On Wed, Aug 29, 2018 at 09:59:07AM +0100, Richard Sandiford wrote: >> > Jakub Jelinek <ja...@redhat.com> writes: >> > > On Tue, Aug 28, 2018 at 12:24:06PM +0100, Richard Sandiford wrote: >> > >> The point of this patch is to put pattern statements in the same >> > >> vec_basic_block as the statements they replace, with the pattern >> > >> statements for S coming between S and S's original predecessor. >> > >> This removes the need to handle them specially in various places. >> > > >> > > My preferred way to handle pattern stmts would be to do what we do in >> > > tree-if-conversion, i.e. whenever creating first pattern stmt for certain >> > > loop, duplicate that loop directly in the IL guarded with an ifn >> > > and modify directly one copy of the loop (the one meant to be >> > > vectorized). >> > > If we aren't cycling over multiple vectorization factors, that >> > > could be even >> > > done directly on the tree-if-conversion created vector loop copy, >> > > otherwise >> > > we'd need more. >> > >> > I'd originally tried adding the pattern stmts to the gimple bb as well >> > as the vec_basic_block, but the problem is that we create pattern stmts >> > before duplicating the scalar loop for peeling. So I think we'd need to >> > copy the loop even for the single-size case, or arrange some other way of >> > temporarily restoring the original code. >> >> Sure, if tree-if-conversion doesn't copy the loop and for single-size case, >> we'd need to do that copy (once per loop), if it already copied the loop, >> there is already the scalar and for vectorization only loop. >> With those copies you don't need to roll back anything, just ensure the >> guarding internal fns fold to constants when the vectorization is over based >> on if the loop was vectorized and with what vf, and cfg cleanup will do the >> rest. >> The vectorizer already has code to find the scalar loop in the >> LOOP_VECTORIZED condition guarded else block. > > My hope is still that we can eventually get rid of pattern stmts - I see how > they make things easier, esp. for the issue of computing a vectorization > factor ...
They seem like a really nice feature to me :-) Doing pattern recognition earlier (e.g. in a prepass) would be a problem because not all vector sizes provide the same features. And doing pattern recognition on the fly during stmt analysis would make it harder to implement some of the more global transforms. At the moment pattern stmts seem pretty light-weight too. Thanks, Richard
