This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GOOGLE] Disable -fdevirtualize by default


> 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 <hubicka@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 <hubicka@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 | tejohnson@google.com | 408-460-2413


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]