Re: [tree-ssa] Another DFA fix

[Diego Novillo <dnovillo at redhat dot com>]

On Wed, 2003-04-30 at 13:26, law@redhat.com wrote:

> Oh how I wish I had gotten involved in this code earlier, then I might
> know why we have this tendency to ignore operands of ADDR_EXPRs....
> 
You did.  We talked on the phone/mail about ADDR_EXPRs last summer (mid
Aug).  But things have changed a bit since then :)

ADDR_EXPRs are special in that:

1- The variable/expr they refer to must be marked as "needed".  This
implies that we should probably make it an operand.

2- An ADDR_EXPR is not really a load of the expression it references. 
It merely takes its address, so making it an operand does not really
make sense.

Back in September, I introduced an attribute M_ADDRESSOF that would
modify a V_USE operand saying that the variable is not loaded but its
address is needed
(http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01101.html).

But once we moved to a rewriting form, I didn't translate M_ADDRESSOF
into something that made sense.  I just started ignoring ADDR_EXPR. 
That's wrong.

> While analyzing testsuite failures for my useless crud removal pass
> I ran into this little gem....  Consider this code:
> 
>         
> bar (d)
> {
>   struct foo * u.1;
>   struct foo u;
>   
>   u.d = d_1;
>   u.1_4 = &u_3;
>   return (int)u.1_4;
> }
> 
> The statement u.1_4 = &u_3 has no uses or vuses because the DFA code
> ignores most ADDR_EXPR expressions.  That seems, well, wrong.
> 
Yeah.  But I don't think you should be renaming 'u' in that ADDR_EXPR. 
Suppose

	int v;
	v_2 = 3;
	p_5 = &v_2;
	...
	return (int)p_5;

If we constant propagate 3 into 'p = &v_2', we have problem.  That was
the reason why I had added M_ADDRESSOF before.  Perhaps we could do the
same with a VUSE?


> 	* tree-dfa.c (get_expr_operands): Do not ignore operands of an
> 	an ADDR_EXPR if it is a PARM_DECL or VAR_DECL.
> 
I would vote for not ignoring, at all.  Perhaps we should create a
virtual use for the operand of the ADDR_EXPR.


Diego.