This is the mail archive of the
mailing list for the GCC project.
Re: [patch] tree-vrp.c: Remove has_assert_expr.
> 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
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,
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
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.