This is the mail archive of the 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: [PATCH] Sanitize block partitioning under -freorder-blocks-and-partition

> 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 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

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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]