[middle-end, patch 4/9] Overhaul of modification analysis
Razya Ladelsky
RAZYA@il.ibm.com
Tue Jul 15 09:26:00 GMT 2008
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
More information about the Gcc-patches
mailing list