This is the mail archive of the
mailing list for the GCC project.
Re: [GOOGLE] Disable -fdevirtualize by default
- From: Teresa Johnson <tejohnson at google dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Xinliang David Li <davidxl 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:10:48 -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>
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
On Sat, Oct 18, 2014 at 4:22 PM, Jan Hubicka <firstname.lastname@example.org> 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)
> 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
>> >> On Sat, Oct 18, 2014 at 10:10 AM, Jan Hubicka <email@example.com> 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 | firstname.lastname@example.org | 408-460-2413