On Sat, Oct 18, 2014 at 3:23 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> 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? >
Not sure -- I will do some experiment. >> 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. This is likely -- we will study this more in details later. >> >> 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? This is certainly better if also solves the problem, but will do that later after our internal release is out. We hit the size and slow instrumentation build issue pretty late in the cycle. >> >> 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 The virtual functions will be emitted in some modules, right? If they are hot, they will be included with the auxiliary modules. Note that LIPO indirect call profile will point to the comdat copy that is picked by the linker in the instrumentation build, so it guarantees to exist. David > > 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
