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