This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Sanitize block partitioning under -freorder-blocks-and-partition
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Teresa Johnson <tejohnson at google dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "marxin.liska" <marxin dot liska at gmail dot com>
- Date: Wed, 2 Oct 2013 20:10:10 +0200
- Subject: Re: [PATCH] Sanitize block partitioning under -freorder-blocks-and-partition
- Authentication-results: sourceware.org; auth=none
- References: <20130831160420 dot GC7492 at kam dot mff dot cuni dot cz> <20130831214614 dot GA12372 at kam dot mff dot cuni dot cz> <CAAe5K+U8kAu8epSpUEMyY4bV_rTxxw78reSvu431w1fOxKkw9A at mail dot gmail dot com> <20130924175727 dot GA24697 at kam dot mff dot cuni dot cz> <CAAe5K+VEWv8Tb-zbUGQHimvXd7SYh+690RC78tgAnmppgwpG6w at mail dot gmail dot com> <20130926220209 dot GB13383 at kam dot mff dot cuni dot cz> <CAAe5K+XEmfA7gwZrBgFALtXMwAmbn0XPdF_CtMA1uEqXq5oyRQ at mail dot gmail dot com> <CAAe5K+VWqnrXetiq3kUE6Tbb45FOm-6ANh9HoJ4s25O1vJk33g at mail dot gmail dot com> <20131002161917 dot GD7181 at kam dot mff dot cuni dot cz> <CAAe5K+Vrt07aHBx_SOGEPbAwA4_9RvGS+vVGjoQW7nDQE147mA at mail dot gmail dot com>
> But why do we want to consider blocks as "probably never executed"
> when the frequency suggests they are sometimes executed?
Well, probably never executed is mean to reffer to one run. If you have
something like code handling fatal errors, you probably still want to have it
in cold secion even if user may have trained the program on a testsuite that
triggers them once or twice per thousdand of runs.
We may just make the predicate more strict, but lets do that incrementally so
we know how much things change.
I am somewhat concerned that we are not that effective on breaking
out cold code so -fprofile-use does not lead to as significant code
size reductions as the theory would suggest, so perhaps I am just overfly
conservative about this. Getting the splitting to work reliably is
definitely going to be a win.
> Perhaps we really need two different interfaces to test for different
> levels of coldness:
> -> returns true when there is profile information for the function
> and the bb has 0 count and 0 frequency.
> -> invoked from bb-reorder.cc to drive function splitting
> -> may want to consider invoking this as an additional check before
> putting function into unlikely text section in the future.
> -> essentially the existing logic in probably_never_executed_bb_p
> -> invoked when marking the cgraph node
Advantage of hot/normal/cold split is that it is easy to understand, but if
necessary (i.e, it becomes impossible to tune well) we may add more stages...