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


Martin Jambor <mjambor@suse.cz> wrote on 14/07/2008 19:36:09:

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

Yes, this should be right, TREE_ADDRESSABLE should already be updated 
correctly
at this phase, I remember also making sure that it is so :)


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