[PATCH] Extend store ccp
Richard Guenther
rguenther@suse.de
Thu Apr 26 15:24:00 GMT 2007
On Thu, 26 Apr 2007, Revital1 Eres wrote:
> 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.
Yes. In fact FRE can also look through loads/stores (at least if
one fixes PR31651). I think we should wait for Danny to submit his
VN changes which will allow more of this to happen.
I also remember problems with your suggested scheme, quoting from
the above mail:
"(but at the same time making the stores propagation barriers due to
limitation to single-outputs of the propagator)."
I don't exactly remember what was the problem ;) So ...
> > 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.
... during propagation didn't work for some reason.
Richard.
More information about the Gcc-patches
mailing list