This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 6/6] Devirtualization in ipa-cp
- From: Martin Jambor <mjambor at suse dot cz>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 11 Mar 2010 14:19:52 +0100
- Subject: Re: [PATCH 6/6] Devirtualization in ipa-cp
- References: <20100213180136.555197900@alvy.suse.cz> <20100213180157.672522451@alvy.suse.cz> <20100222160805.GE3140@atrey.karlin.mff.cuni.cz>
Hi,
On Mon, Feb 22, 2010 at 05:08:05PM +0100, Jan Hubicka wrote:
> > @@ -531,6 +537,16 @@ ipcp_cloning_candidate_p (struct cgraph_
> > return true;
> > }
> >
> comments ;) How this is different from BOTTOM in the lattice?
I have added the missing comment. cannot_devirtualize is basically
BOTTOM for devirtualization. However these two are distinct values.
For example, sometimes we cannot propagate a constant because an
ADDR_EXPR of a local variable is passed in an argument, so the IPA-CP
lattice is BOTTOM, but we still can propagate the type for
devirtualization. Or there may be different constants passed to a
function, again resulting to IPA-CP BOTTOM lattice for the parameter,
but we still might build and use a list of their types. Conversely,
even if we propagate an IPA constant in IPA-CP, its type might not
have any BINFO associated with it and therefore we cannot use the
parameter for devirtualization.
>
> The patch overall seems to make sense. Please add describing
> comment on the top of ipa-cp as we are now diverging from classical
> ipa-cp formulation somewhat (but I can't seem to justify separate
> devirtualization pass that would do precisely the same as ipa-cp
> does but at types only)
Thanks, I have added that comment too and will resubmit the patches
soon.
Martin