[PATCH] Fix PR59993

Richard Biener rguenther@suse.de
Fri Jan 31 09:24:00 GMT 2014


On Thu, 30 Jan 2014, Marc Glisse wrote:

> On Thu, 30 Jan 2014, Richard Biener wrote:
> 
> >    /* Associate (p +p off1) +p off2 as (p +p (off1 + off2)).  */
> >    ptr = gimple_assign_rhs1 (stmt);
> >    off1 = gimple_assign_rhs2 (stmt);
> > !   if (TREE_CODE (ptr) != SSA_NAME
> > !       || !has_single_use (ptr))
> >      return false;
> >    def_stmt = SSA_NAME_DEF_STMT (ptr);
> >    if (!is_gimple_assign (def_stmt)
> > !       || gimple_assign_rhs_code (def_stmt) != POINTER_PLUS_EXPR
> > !       || !can_propagate_from (def_stmt))
> >      return false;
> >    ptr = gimple_assign_rhs1 (def_stmt);
> >    off2 = gimple_assign_rhs2 (def_stmt);
> 
> Hello,
> 
> we have 2 helpers get_prop_source_stmt and defcodefor_name in
> tree-ssa-forwprop.c, but you don't seem to like them. Do they have a
> particular drawback or is it just easier to rewrite the code than to remember
> how to use those? I am asking so I know whether I can / should use them in my
> future patches.

I don't like them too much - get_prop_source_stmt possibly causes
quadratic compile-time complexity and defcodefor_name is just
ugly ;)

To get rid of get_prop_source_stmt I'd like to move towards
keeping a simple SSA value lattice in forwprop so one can
get at the constant or SSA name a SSA name is a copy of in O(1)
(similar to the copyprop lattice).

defcodefor_name ... well, I hope to get started on a
meta-description to tree / GIMPLE pattern matching machinery
(and build our folders upon that) soon.

Richard.



More information about the Gcc-patches mailing list