> On 12/11/2013 08:55 AM, Jan Hubicka wrote: > >>>>+ /* Don't clone decls local to a comdat group. */ > >>>>+ if (comdat_local_p (node)) > >>>>+ return false; > >>> > >>>Why? It seems this should work if the clone becomes another comdat local? > >> > >>Right, I think the problem was that the clone wasn't becoming comdat > >>local. And for the specific case of decloning, there's no point in > >>cloning the decloned constructor. > > > >If it does not make sense, how we ended up cloning it? > > I guess the heuristics are making a mistake. > > >Can you show me some code sample of decloning? > > >I assume that we basically turn original cloned constructors into wrappers > >around common "worker" that is now comdat local. > > Right. > > >I think ipa-cp may end up > >deciding on clonning the wrapper that will break because it will end up > >static > >calling the local comdat function. > >On the other hand it may decide to clone both the wrapper and the actual > >function > >and in that case bringing both static is fine. > > In the case I'm looking at (g++.dg/torture/pr41257.C, with decloning > forced on), we're cloning the local function in order to propagate > in a '0' passed in from one of the wrappers. This is pointless > because the wrapper contains just the one call, so in any situation > where cloning makes sense, inlining is better.
ipa-cp does not really contain heuristic to figure out where cloning makes more sense than inlining basically because if we produce such clone, inliner will inline it anyway. It is harder than it may seem to isolate testcases where inlining is always a win. > > So, it's probably possible to make it work to clone the comdat local > function into another comdat local function, but it's not useful, > and it's easier to just prevent it. Yep, with current limited use of comdat locals I guess it makes sense. Honza > > Jason
