> On 09/10/2014 06:47 PM, Jan Hubicka wrote: > >Again - I think main problem is that we provide a middle end a function body > >that it is not allowed to use. We do not really have a concept of function > >definitions that we may not use and worse yet, we are preventing that just in > >one special case - i.e. in the speculative devirtualization. > > Because that special case is the only time we want to prevent it, as > I argued in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678#c19 > > My patch shouldn't change any behavior except for fixing this LTO > bug, since implicitly-declared member functions always have vague > linkage. It seems to me a simple, safe fix.
Your patch disables speuclative devirtualization to all implicitely produced destructors. At LTO, in typical case, we can safely devirtualize those. This is because constructors and thus virutal tables are likely all part of the given LTO translation unit (if it is close to whole program) and thus the body of virtual destructor will be output anyway. That is why I think we can just avoid privatizing of these when they are not used directly already. But I guess especially for 4.9 branch you patch is safe and practical, so lets go with it (both mainline and branch) and I will try to get some stats on how many devirtualizations are missed this way. Honza
