This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] tree-ssa-ccp.c: Propagate even more ADDR_EXPRs.
- From: Jeffrey A Law <law at redhat dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 31 May 2005 08:43:58 -0600
- Subject: Re: [RFC] tree-ssa-ccp.c: Propagate even more ADDR_EXPRs.
- References: <20050527.164221.32174793.kazu@cs.umass.edu>
- Reply-to: 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