> 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: > > probably_never_executed() > -> 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. > > possibly_never_executed() > -> essentially the existing logic in probably_never_executed_bb_p > -> invoked when marking the cgraph node Perhaps... 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... Honza
