On Sat, Oct 18, 2014 at 4:22 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> >> 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. > > If you have COMDAT virtual inline function that is used by module FOO and > LIPO's indirect inlining will work out that it goes to comdat copy of module > BAR > (that won the merging). It will make C++ parser to also parse BAR to get > the function, but callgarph builder will ignore it, too. > (this is new logic in analyze_function that with -fno-devirtualize will just > prevent all virtual functions not directly reachable to appear in symbol > table)
For LIPO, modules are parsed independently -- their initial callgraphs are also mostly isolated (except for builtin nodes) before LIPO linking happens. LIPO will guarantee that an aux module is processed exactly the same as (before tree-profile pass) in the the instrumentation build. > > I am surprised you hit the size limits with 4.9 only - for quite some time > we keep all virtual functions in callgarph until inlining. In fact 4.9 is > first > that works harder to drop them early (because I hit the problem with LTO > where they artifically bloat the size of LTO object files) We can dig it more to later understand why only 4.9 hits the problem. My size results with -fno-devirtualize-speculatively is out. It shrinks size by 1.68% -- slightly more than -fdevirtualize can do in O2 compile. By the way, you mentioned 'hacking the ipa.c:walk_polymorphic_call_targets to not make the possible targets as reachable' -- is that something worth doing in trunk? With that, we can probably just turn off speculative devirtualization. David > > Honza >> >> 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
