[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