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]

[RFC][PATCH] Extend store ccp


Hello,

Following previous review
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01787.html); attached is
the patch which enhance store ccp to propagate constants from stores to
loads when the current implementation fails due to alias uncertainty;

For example:

S[5].x = 4;
S[5].y = 0;

x = S[5].x;

===>

S[5].x = 4;
S[5].y = 0;

x = 4;

This transformation extend the current implementation of the ccp propagator
in two places:

1) When a store stmt is visited - until now the propagator added an edge
for all the immediate uses of the store which is a problem when we want
to propogate constants to non-immediate uses as well.

For example consider the following code:

         1) arr[i].x = tmp1;
         ...
         2) arr[i].y = tmp2;
         ...
         3) reg1 = arr[i].x;
         ...
         4) arr[i].z = tmp2;
         ...
         5) reg2 = arr[i].x;

When stmt no. 1 is visited we want to add stmt 3 and 5 to the worklist
so they will be updated if stmt 1's lattice value was changed.  This is
taken care of in add_ssa_edge function ().

2) When load stmt is visited - until now the propagator propagated
constants by looking at the immediate vdefs of the load, this was again
a changed as we wanted to propagate constants from the non-immediate
vdefs as well.  This is taken care of in get_stmt_rhs_def_stmt ()
function originally written by Richard Guenther.

The major concern is to ensure that if we propagate a value to a load
from it's store we could also be able to add this load to the worklist
once the latice value of this store is been changed; so the load's
lattice value could be updated if needed afterwords.

Another concerns was to ensure that the functionality of add_ssa_edge
() function remains the same as other optimizations which do not walk
the virtual use-def chain to retrieve the exact memory reference use
it.

One more issue - in the previous version of this patch
(http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01519.html) I used
a parameter to ensure that the last propagation which is done in
replace_vuses_in () will use the new function get_stmt_rhs_def_stmt only
for store ccp optimization while other optimizations which might use
the propagator will use the original function - get_value_loaded_by ().
I omitted this parameter in this patch but I still think its needed for
consistency (although it seems to do no harm) as those analyses which
did not use get_stmt_rhs_def_stmt during their analysis phase should
not use it in their final stage also.

ChangeLog entry:

2007-06-19  Revital Eres  <eres@il.ibm.com>

        * tree-ssa-ccp.c (visit_assignment): Call get_stmt_rhs_def_stmt
        while performing the propagation.
        * tree-ssa-propagate.c (do_store_ccp): New function.
        (add_edge): New function.
        (add_ssa_edge): Add an edge for every use by walking the virtual
        def-use chain.
        (get_stmt_rhs_def_stmt): New function to get
        the defining stmt of a use by walking the virtual use-def chain.
        (replace_vuses_in): Call get_stmt_rhs_def_stmt
        to perform the final replacement.
        * tree-ssa-propagate.h (get_stmt_rhs_def_stmt): Declare.
        * tree-flow.h (offset_overlaps_with_access): Declare.

Comments are welcome.
Thanks,
Revital


(See attached file: patch_ccp_19_6.txt)(See attached file: store_ccp-1.txt)

Attachment: patch_ccp_19_6.txt
Description: Text document

Attachment: store_ccp-1.txt
Description: Text document


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