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] 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



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