Re: [patch] tree-vrp.c: Remove has_assert_expr.

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi Diego,

> So, you will need to extend update_ssa's API to give you the new
> names that replace an old one.  That way, you can check whether
> the condition that generated the replacement is the same one as
> COND.

In other words, you want an equivalent of SSA_NAME_DEF_STMT that works
when update_ssa is pending?  I have a question.

If I understand update_ssa correctly, old_names and new_names are
one-to-many relationships.  In other words, we may have

  p_1 = foo ();
  p_1->a = 0;
  p_2 = ASSERT_EXPR <p_1, p_1 != 0B>;
  p_1->b = 0;
  p_3 = ASSERT_EXPR <p_1, p_1 != 0B>;
  p_1->c = 0;
  p_4 = ASSERT_EXPR <p_1, p_1 != 0B>;

while update_ssa is pending.  Suppose you are looking at "p_1->c = 0;"
to see if you can infer a value range out of it.  You want to get to a
statement defining the p_1 in "p_1->c = 0;".  We have several choices,
namely

  p_1 = foo ();
  p_2 = ASSERT_EXPR <...>;
  p_3 = ASSERT_EXPR <...>;

Of course, the correct answer is p_3, the one that p_1 in "p_1->c =
0;" will be renamed to by update_ssa.  But how do we differentiate p_2
and p_3?  They may be defined in the same basic block, so the
combination of bb_for_stmt and dominated_by_p may not help.  Would you
walk statements in the basic block to see which of p_2 and p_3 comes
first?

What if we have insertions on edges?  We can't quite pretend that an
SSA_NAME defined on an edge to be defined in e->src, I guess.

If we want some sort of an approximation, we can just look at the
basic blocks where new SSA_NAMEs are defined in.  Otherwise, we may
need some trick to easily get to p_3 above.

Kazu Hirata