> Devirtualization needs more tuning to be usable internally. We have > seen 1.6% size increase on average, but unnoticable performance
Does that happen with -fno-devirtualize-speculatively? > improvement with this option on. I would rather use the size budget to > make inliner more aggressive :) :) Well, that is what devirtualization is supposed to do. All it does is converting indirect calls to direct calls that can increase size only if extra inlining happens. Speculative devirtualization will increase code size, but 1% seems quite off - you would need very many virtual calls in the code to get close to that. Also it turns itself off with profile feedback. You can try -fno-devirtualize-speculatively Thinking about it perhaps what really happens is the following: You have a lot of potentially reachable virtual functions in header and those are kept alive until inlining because one of virtual calls in your unit may be devirtualized to them (change to 4.8 is that we no longer keep all virtual functions, just those that may be reached). This increase unit size estimates and thus gives inliner more budget to inline until it hits inline-unit-growth limits. > > For instrumentation build, some of our builds will reach the build > machine limit with this option on. Can you try to just disable the reachability code in ipa.c (as I wrote earlier) and see if it makes difference? > > In LIPO mode, the compiler uses indirect target profile counter to > build fake edges in order to keep the targets alive -- this is > probably the reason we do not see an performance impact. Does it? With -fno-devirtualize you won't even get the virtual functions added into the callgraph unless you disable the logic in cgraphunit.c Honza > > David > > > On Sat, Oct 18, 2014 at 10:10 AM, Jan Hubicka <hubi...@ucw.cz> wrote: > >> Disabling devirtualization reduces code size, both for instrumentation > >> (because > >> many more virtual functions are kept longer and therefore instrumented) > >> and for > >> normal optimization. > > > > OK, with profile instrumentation (that you seem to try to minimize) i can > > see > > how you get noticeably more counters because virtual functions are kept > > longer. > > (note that 4.9 is a lot more agressive on removing unreacable virtual > > functions > > than earlier compilers). > > > > Instead of disabling -fdevirtualize completely (that will get you more > > indirect > > calls and thus more topn profiling) you may consider just hacking > > ipa.c:walk_polymorphic_call_targets to not make the possible targets as > > reachable. (see the conditional on before_inlining_p). > > > > Of course this will get you less devirtualization (but with LTO the > > difference > > should not be big - perhaps I could make switch for that for mainline) and > > less > > accurate profiles when you get speculative devirtualization via topn. > > > > I would be very interested to see how much difference this makes. > > > > Honza
