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


> 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

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]