This is the mail archive of the
mailing list for the GCC project.
Re: [patch] tree-vrp.c: Remove has_assert_expr.
On Wed, May 04, 2005 at 12:28:44PM -0400, Kazu Hirata wrote:
> 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.
No, we won't. The names p_3 and p_4 won't be inserted because
when we try to insert p_3, has_assert_expr will return 'true' for
p_1. If we had allowed p_3 and p_4 to be created, then yes we
would get to this situation.
> 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.
Hmm, we have a similar problem here. Initially, has_assert_expr
was supposed to prevent this situation:
if (p_3 != 0)
*p_3 = ...
assertified into (before update_ssa):
1 if (p_3 != 0)
2 p_5 = ASSERT_EXPR <p_3, p_3 != 0>
3 *p_3 = ...
4 p_4 = ASSERT_EXPR <p_3, p_3 != 0>
6 = *p_3
7 p_6 = ASSERT_EXPR <p_3, p_3 != 0>
As you noted, it actually doesn't. The additional
check I suggested will get rid of the assertions at line 7. But
it will not get rid of the test at line 4 because that is
actually the *first* assert that we insert. The edge assertion
happens after we insert the check at line 4.
Let me think about this a bit. This whole assert insertion
mechanism needs to be revamped.