> On 12/11/2013 10:11 AM, Jason Merrill wrote: > >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. > > Well, not that much easier actually. I'm attaching both a delta > from my last patch and a complete patch against trunk. Two > questions: > > Do you have an opinion about which way to implement symtab_in_same_comdat_p?
I would go with the #if 1 case. Don't seem to justify a loop that is trivially replaceable by comdat. In longer term the plan is to move all those visibility fields from trees into symbols and in that case I am sure we will end up having the comdat group name in there too. > > Is ipa_passes the right place to initialize calls_comdat_local? The flag is probably needed in both early inliner and IPA inliner. A conservative place to initialize it would be in inline_analyze_function. (early inliner analyze function twice, first before inlining and next after early optimization, so the update should also clear the flag if call disapeared). I think we also want to clear it if call to comdat local function is marked inline. This is only way we can end up inlining those constructors now, right? inlining ctors/dtors of course is rather important for further optimization, so we should be cureful to not regress optimization here too much. We will still lose some propagation since inliner won't work out that it can propagate something useful through the wrapper call (unlike ipa-cp that would if it knew how to clone local comdats). I am on way home, I will look in detail on patch next. Honza
