Re: [GOOGLE] Disable -fdevirtualize by default

[Teresa Johnson <tejohnson at google dot com>]

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.

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