This is the mail archive of the
mailing list for the GCC project.
Re: [GOOGLE] Disable -fdevirtualize by default
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Xinliang David Li <davidxl at google dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Teresa Johnson <tejohnson at google dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 19 Oct 2014 00:23:15 +0200
- 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>
> Devirtualization needs more tuning to be usable internally. We have
> seen 1.6% size increase on average, but unnoticable performance
Does that happen with -fno-devirtualize-speculatively?
> improvement with this option on. I would rather use the size budget to
> make inliner more aggressive :)
:) Well, that is what devirtualization is supposed to do. All it does is converting
indirect calls to direct calls that can increase size only if extra inlining happens.
Speculative devirtualization will increase code size, but 1% seems quite off - you
would need very many virtual calls in the code to get close to that. Also it turns
itself off with profile feedback. You can try -fno-devirtualize-speculatively
Thinking about it perhaps what really happens is the following: You have a lot
of potentially reachable virtual functions in header and those are kept alive until
inlining because one of virtual calls in your unit may be devirtualized to them
(change to 4.8 is that we no longer keep all virtual functions, just those that may
be reached). This increase unit size estimates and thus gives inliner more budget
to inline until it hits inline-unit-growth limits.
> For instrumentation build, some of our builds will reach the build
> machine limit with this option on.
Can you try to just disable the reachability code in ipa.c (as I wrote earlier)
and see if it makes difference?
> In LIPO mode, the compiler uses indirect target profile counter to
> build fake edges in order to keep the targets alive -- this is
> probably the reason we do not see an performance impact.
Does it? With -fno-devirtualize you won't even get the virtual functions added
into the callgraph unless you disable the logic in cgraphunit.c
> 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