On Fri, Feb 10, 2012 at 04:22:32PM +0100, Richard Guenther wrote:
> On Fri, Feb 10, 2012 at 3:39 PM, William J. Schmidt
> <wschm...@linux.vnet.ibm.com> wrote:
> > Jakub, thanks! Based on this, I believe the patch is correct in its
> > handling of the STMT_VINFO_PATTERN_DEF_SEQ logic, without any double
> > counting.
> >
> > I misinterpreted what the commentary for vect_pattern_recog was saying:
> > I thought that all replacements were hung off of the last pattern
> > statement, but this was just true for the particular example, where only
> > one replacement statement was created. Sorry for any confusion!
> >
> > Based on the discussion, is the patch OK for trunk?
>
> But you still count for each of the matched scalar stmts the cost of the
> whole pattern sequence. No?
For each stmt you should count the original stmt if it is relevant
(I think there are cases where both the original stmt and pattern stmt for
it are both relevant and emitted, didn't understand it exactly though,
but usually only the orig or only the pattern stmts are relevant),
and if STMT_VINFO_IN_PATTERN_P, count the STMT_VINFO_RELATED_STMT (if any)
and all STMT_VINFO_PATTERN_DEF_SEQ sequence stmts (if any), again, not sure
if STMT_VINFO_RELEVANT needs to be tested for each or not.
I guess look at what we actually emit if the cost model says it should be
emitted.
Neither the STMT_VINFO_PATTERN_DEF_SEQ nor STMT_VINFO_RELATED_STMT
are shared in between any orig stmts, each has its own set of stmts.
I believe if some original stmt should map to no pattern stmts, it isn't
marked as STMT_VINFO_IN_PATTERN_P at all, but as nothing uses its lhs
with the pattern stmts in place, it won't be relevant and will be ignored.
Jakub
