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: [middle-end, patch 4/9] Overhaul of modification analysis


Hi,

On Thu, Jul 10, 2008 at 04:17:17PM +0200, Jan Hubicka wrote:
> > This patch is  a rewrite of modification analysis  done by ipa-cp.  It
> > is not really  crucial for ipa-cp itself but  is hopefully cleaner and
> > has  extended   capabilities  required  for   indirect  inlining.   In
> > particular, it  does not mark  all addressable parameters  as modified
> > but  only  those  that  are  really  modified  or  their  address  was
> > explicitly taken in the given  function.  This is necessary so that we
> 
> There is early pass clearing the ADDRESSABLE flag in such cases.  Are
> you still seeing variables marked as ADDRESSABLE that don't have their
> ADDR_EXPRs?

Well...  actually  no.  I guess  I confused TREE_ADDRESSABLE  with the
needs_to_live_in_memory()  predicate.   Getting   all  the  flags  and
predicates right is  sometimes tough for me. :-/  Anyway, this means I
can  simplify the  modification analysis  to only  examine  right hand
sides of assignment statements.  I'll submit a new version soon.

> 
> > @@ -114,8 +123,8 @@ struct ipa_node_params
> >    struct ipcp_lattice *ipcp_lattices;
> >    /* Mapping each parameter to its PARM_DECL tree.  */
> >    tree *param_decls;
> > -  /* Indicating which parameter is modified in its function.  */
> > -  bool *modified_flags;
> > +  /* Various flags describing individual parameters.  */
> > +  struct ipa_param_flags *param_flags;
> >    /* Only for versioned nodes this field would not be NULL,
> >       it points to the node that IPA cp cloned from.  */
> >    struct cgraph_node *ipcp_orig_node;
> 
> Can't this be just array of structures describing each formal argument?
> 

I'm afraid I am not sure I understand what you mean here.

If you think that a formal parameter should be described by one larger
element of a  single array rather than a  multitude of simple elements
of different arrays, then I'd say that yes, it is certainly so, I just
have not reached that iteration of rewriting ipa-prop yet :-)

I'll have a look at where that change would be best done. 

Thanks,

Martin


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