> Hi Honza, > > As David says, we will do some more experiments with the change you > suggest and speculative devirtualization, but we needed to make this > change in part to get an internal release out. One of the issues was a > recent change to cp/decl2.c to make virtual function decls needed > under flag_devirtualize.
I think that one is not in current 4.9 branch (only in mainline). Honza > > Thanks! > Teresa > > 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) > > > > 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) > > > > 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 > > > > -- > Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
