On Fri, Feb 10, 2012 at 07:31:01AM -0600, William J. Schmidt wrote:
> >From the commentary at the end of tree-vect-patterns.c, only the main
> statement in the pattern (the last one) is flagged as
> STMT_VINFO_IN_PATTERN_P. So this is finding the new replacement
> statement which has been created but not yet inserted in the code. It
> only gets counted once.
STMT_VINFO_IN_PATTERN_P is set on the vinfo of the original stmt (and not
just the last, but all original stmts that are being replaced by the
pattern). Each of these has STMT_VINFO_RELATED_STMT set to a pattern stmt
(last one corresponding to that original stmt). If needed, further
pattern stmts for that original stmts are put into
STMT_VINFO_PATTERN_DEF_SEQ. The pattern matcher could e.g. match
3 original stmts, and stick a single pattern stmt into STMT_VINFO_RELATED_STMT
on the first original stmt, then say 2 pattern stmts into
STMT_VINFO_PATTERN_DEF_SEQ of the second original stmt plus one
STMT_VINFO_RELATED_STMT and finally one pattern stmt through
STMT_VINFO_RELATED_STMT on the third original stmt.
> Note that STMT_VINFO_PATTERN_DEF_SEQ doesn't exist in the 4.6 branch, so
> this section has to be omitted if we backport it (which is desirable
> since the degradation was introduced in 4.6). Removing it apparently
> does not affect the sphinx3 degradation.
Yeah, when backporting you can basically assume that
STMT_VINFO_PATTERN_DEF_SEQ is always NULL in 4.6 and just write NULL instead
of itt (and simplify), because no pattern recognizers needed more than one
pattern stmt for each original stmt back then.
Jakub
