This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.
>
Yes.

> 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 = ...
	  ...
	   = *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>
     5   ...
     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.


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]