[PATCH] tree level if-conversion for vectorizer

[Richard Henderson]

On Thu, Aug 26, 2004 at 10:29:52AM -0700, Devang Patel wrote:
> On Aug 26, 2004, at 1:56 AM, Richard Henderson wrote:
> >On Wed, Aug 25, 2004 at 10:53:16PM -0700, Devang Patel wrote:
> >>+   num_uses = num_immediate_uses (df);
> >>+
> >>+   for (j = 0; j < num_uses; j++)
> >>+     {
> >>+       tree use = immediate_use (df, j);
> >>+       if (TREE_CODE (use) == PHI_NODE)
> >
> >Why are you iterating over the PHI nodes both here for
> >the modify_expr, and later via the PHI node?  Seems to
> >me the former is sufficient.
> 
> Here I check if modify_expr's result is used in PHI node or not. I 
> check phi arguments. Later I check if PHI_RESULT, which is not 
> is_gimple_reg() is immediatly used in PHI node or not. Here I check if 
> virtual phi is immediately used in another phi or not.

If, when you looked at the PHI's result you also checked the arity of
its arguments, you wouldn't have to traverse immediate uses here.
Which is expensive.

> Yes. This is why I asked you couple of questions regarding - holding 
> value of vector compare.

Ah yes, I forgot about this.  Yes, you will want to force the compare
into a register.  Not for the sake of the COND_EXPR, but for sake of
vectorization.  Please add a comment to that effect.

> May be because the way I follow my thought process?
> How would you do otherwise?

The backward use->def link can be followed trivially by SSA_NAME_DEF_STMT.
This information is always around.  The forward def->use link must be
computed separately, and takes extra effort.

> >I suppose that (void)0 is supposed to be from the default statement?
> >Suppose you do not find a sibling for this conditional, because the
> >variable really was only partially set in the original.  Do you leave
> >this invalid code hanging about, or do you simplify to "T1 = B"?
> 
> What if there is no corresponding sibling in B2?
> modify_expr from B1 needs COND. If COND is true, I simplify.

That doesn't answer the question.

> >And given that this doesn't start with "case COND_EXPR:"
> >I'll claim you've done it in the wrong place.
> 
> It is inside MODIFY_EXPR. In build_ssa_operands, as well as 
> get_expr_operands, I handle each operands of COND_EXPR separately.

PLUS_EXPR is also inside MODIFY_EXPR, yet you don't see that special
cased in either of those places.  You're doing something wrong.


r~