This is the mail archive of the
mailing list for the GCC project.
Re: [GOOGLE] Disable -fdevirtualize by default
- From: Xinliang David Li <davidxl at google dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Teresa Johnson <tejohnson at google dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 18 Oct 2014 17:14:13 -0700
- Subject: Re: [GOOGLE] Disable -fdevirtualize by default
- Authentication-results: sourceware.org; auth=none
- References: <CAAe5K+Wi0UtgdkOdZFRRQTPwHbSB5SOhhv4Rj1OHVgwDgbk7dw at mail dot gmail dot com> <20141018171034 dot GH11581 at atrey dot karlin dot mff dot cuni dot cz> <CAAkRFZKWTQhqNhpvcAtjwAsM5qrErm1=3PuYfDWcnqO2a5yaVA at mail dot gmail dot com> <20141018222314 dot GB17993 at kam dot mff dot cuni dot cz> <CAAkRFZJqEsGeCL=2b4PUE159oKH_yKfB8KgxCHYStd0K2X9AgQ at mail dot gmail dot com> <20141018232219 dot GA11506 at kam dot mff dot cuni dot cz>
On Sat, Oct 18, 2014 at 4:22 PM, Jan Hubicka <email@example.com> 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
> 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
> 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
By the way, you mentioned 'hacking the
ipa.c:walk_polymorphic_call_targets to not make the possible targets
reachable' -- is that something worth doing in trunk? With that, we
can probably just turn off speculative devirtualization.
>> > Honza
>> >> David
>> >> On Sat, Oct 18, 2014 at 10:10 AM, Jan Hubicka <firstname.lastname@example.org> 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