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


> 
> 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


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