This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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