This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Extend store ccp
- From: Revital1 Eres <ERES at il dot ibm dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Ayal Zaks <ZAKS at il dot ibm dot com>, Dorit Nuzman <DORIT at il dot ibm dot com>, gcc-patches at gcc dot gnu dot org, rguenther at suse dot de, Victor Kaplansky <VICTORK at il dot ibm dot com>
- Date: Thu, 26 Apr 2007 18:12:20 +0300
- Subject: Re: [PATCH] Extend store ccp
Hello,
Thanks for reviewing this patch.
gcc-patches-owner@gcc.gnu.org wrote on 26/04/2007 17:29:45:
> We could do one better. While following the use-def chain, we could ask
if
> the LHS of the assignment overlaps the RHS that we are trying to replace.
So:
>
> 1 # S_3 = VDEF <S_1>
> 2 S[5].x = 0;
> 3
> 4 # S_4 = VDEF <S_3>
> 5 S[5].y = x_9;
> 6
> 7 # VUSE <S_4>
> 8 x = S[5].x;
> 9
> 10 # VUSE <S_4>
> 11 y = S[5].y;
>
> From statement #8 you go to statement #4, since a store to S[5].y does
> not affect S[5].x (we can use nonoverlapping_component_refs_p as a
> starting point or access_can_touch_variable, for instance).
>
> This will improve both copy and constant propagation.
If think that Richard Guenther submitted a similar
implmenetaion that was not inserted from some reason.
(http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00669.html). The current
implementation is cheaper in terms of compile time as it fails early if
not all the RHS of the VDEFS have the same constant value.
>
> Another problem with the patch is that you are doing this too late.
> Why not do this *during* propagation? In this case, you would allow S_4
to
> assume the lattice value of 0 and use it during propagation.
The call to all_vdef_have_same_lattice_const_value () function which
preforms the analysis was done in two places - One in the ccp analysis
phase in tree-ssa-ccp.c where the lattice values are computed and the
other is in the final propagation. I was not sure whether it is more
appropriate to add a field to prop_value_t structure to eliminate the
extra call in tree-ssa-propogate.c; eventually I choose to call it again.
The reason I added aggressive_store_ccp_p argument; is related to the
above explanation- I wanted to make sure that the replacement is done
only from the ccp analysis and not others that use the propagation
utility for the final replacement.
> > bool
> > -substitute_and_fold (prop_value_t *prop_value, bool use_ranges_p)
> > +substitute_and_fold (prop_value_t *prop_value, bool use_ranges_p,
> > + bool aggressive_store_ccp_p)
>
> The aggressive_store_ccp_p argument is not necessary.
Thanks again,
Revital