It was in upstream 4.9 branch, but got reverted in r215061 to fix PR/61214 and PR/62224.
David On Sun, Oct 19, 2014 at 1:21 AM, Jan Hubicka <hubi...@ucw.cz> wrote: >> 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
