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] [4.2 projects] vectorize type conversions - 2/6


Dorit Nuzman wrote on 02/12/06 08:44:

>   /* Utility functions for the code transformation.  */
>   static bool vect_transform_stmt (tree, block_stmt_iterator *);
>   static tree vect_create_destination_var (tree, tree);
>   static tree vect_create_data_ref_ptr
> !   (tree, block_stmt_iterator *, tree, tree *, tree *, bool);
>   static tree vect_create_addr_base_for_vector_ref (tree, tree *, tree);
>   static tree vect_setup_realignment (tree, block_stmt_iterator *,
tree *);
> + static tree bump_vector_ptr (tree, tree, block_stmt_iterator *, tree);
>   static tree vect_get_new_vect_var (tree, enum vect_var_kind, const
char *);
>   static tree vect_get_vec_def_for_operand (tree, tree, tree *);
> + static tree vect_get_vec_def_for_stmt_copy (enum vect_def_type, tree);
>
Don't forward declare static functions.  The convention is to define
them before first use and only forward declare if there are circular
references.

A patch to remove the existing forward declarations is pre-approved.

>   /* Function vect_create_data_ref_ptr.
>
> !    Creat a new pointer to vector type (vp), that points to the first
location
s/Creat/Create/

> !    accessed in the loop by STMT, along with the def-use update chain to
> !    appropriately advace the pointer through the loop iterations.
Also set
>
s/advace/advance/

> +   incr_stmt = build2 (MODIFY_EXPR, vptr_type, ptr_var,
> +                 build2 (PLUS_EXPR, vptr_type, dataref_ptr, update));
>
MODIFY_EXPRs should be of type void_type_node, though I think we are
somewhat loose in enforcing this property.  The type is not really
used at this level.

> !       copy_virtual_operands (new_stmt, stmt);
> !       if (j == 0)
> ! 	{
> ! 	  /* The original store is deleted so the same SSA_NAMEs can be used.
> ! 	   */
> ! 	  FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_VMAYDEF)
> ! 	    {
> ! 	      SSA_NAME_DEF_STMT (def) = new_stmt;
> ! 	      mark_sym_for_renaming (SSA_NAME_VAR (def));
> ! 	    }
> !
> ! 	  STMT_VINFO_VEC_STMT (stmt_info) = *vec_stmt =  new_stmt;
> ! 	}
> !       else
> ! 	{
> ! 	  /* Create new names for all the definitions created by COPY and
> ! 	     add replacement mappings for each new name.  */
> !           FOR_EACH_SSA_DEF_OPERAND (def_p, new_stmt, iter,
SSA_OP_VMAYDEF)
> ! 	    {
> ! 	      create_new_def_for (DEF_FROM_PTR (def_p), new_stmt, def_p);
> ! 	      mark_sym_for_renaming (SSA_NAME_VAR (DEF_FROM_PTR (def_p)));
> ! 	    }
>
But you are not adding replacement mappings here, you are giving up
and marking the symbols for renaming.  Shortcoming of the way we
update SSA or simplicity?

For now this is fine, but I'd like to see before/after snippets.  If
it's a shortcoming in the way we update the SSA form, I'd like to
address that in the mem-ssa branch.


OK with the above changes.

:REVIEWMAIL:


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