Re: [RFC] tree-ssa-ccp.c: Propagate even more ADDR_EXPRs.

[Jeffrey A Law <law at redhat dot com>]

On Fri, 2005-05-27 at 16:42 -0400, Kazu Hirata wrote:
> Hi,
> 
> Attached is a patch to propagate even more ADDR_EXPRs.
> 
> Consider the testcase.
> 
> struct f {
>   int i;
> };
> 
> int
> foo (void)
> {
>   struct f a;
>   struct f *p;
>   int *q;
> 
>   a.i = 1;
>   p = &a;
>   q = &p->i;
>   return *q;
> }
> 
> We hope to get the last two lines transformed into
> 
>   q = &a.i;
>   return a.i;
> 
> Unfortunately, CCP misses this optimization.  The reason is that CCP
> does not know how to fold &(&a)->i while evaluting q = &p->i.
> 
> The patch fixes the problem by special-casing ADDR_EXPRs in ccp_fold.
> 
> I put "RFC" because I am not sure if this is the best solution.
> Should fold_addr_expr be a part of fold_unary?  Should I also handle
> ARRAY_REFs?
> 
> Tested on i686-pc-linux-gnu.  Comments?
> 
> Kazu Hirata
> 
> 2005-05-27  Kazu Hirata  <kazu@cs.umass.edu>
> 
> 	PR tree-optimization/21636
> 	* tree-ssa-ccp.c (fold_hidden_indirect_ref, fold_addr_expr):
> 	New.
> 	(ccp_fold): Call fold_addr_expr.
> 
> 2005-05-27  Kazu Hirata  <kazu@cs.umass.edu>
> 
> 	PR tree-optimization/21636
> 	* gcc.dg/tree-ssa/pr21636.c: New.
I'm not sure if we want to bother with this in CCP.  The forward 
propagation code already handles this case rather effectively.  What's
the real benefit from doing the same optimization in CCP that we're
already doing in forwprop.c?

[ Now you could argue that all the ADDR_EXPR stuff in forwprop.c could
  be moved into CCP.  They're not really constants or invariants, but
  with some work we could probably convince CCP to handle them.  ]


jeff