[Google] Refine hot caller heuristic

2013-08-20 Thread Easwaran Raman
The current hot caller heuristic simply promotes edges whose caller is hot. This patch does the following: * Turn it off for applications with large footprint since the size increase hurts them * Be more selective by considering arguments to callee when the heuristic is enabled. This performs well

Re: [Google] Refine hot caller heuristic

2013-08-20 Thread Xinliang David Li
Do you need to guard the jump function access with check if (ipa_node_params_vector.exists ())? Ideally, useful_cold_callee should be folded into the inline hints estimation. Question about the heuristic: why filtering out PASS_THROUGH parameter cases completely? Passing 'this' parameter in many

Re: [Google] Refine hot caller heuristic

2013-08-21 Thread Teresa Johnson
> +/* Knob to control hot-caller heuristic. 0 means it is turned off, 1 means > + it is always applied, and 2 means it is applied only if the footprint is > + smaller than PARAM_HOT_CALLER_CODESIZE_THRESHOLD. */ > DEFPARAM (PARAM_INLINE_HOT_CALLER, > "inline-hot-caller", > "Co

Re: [Google] Refine hot caller heuristic

2013-08-29 Thread Easwaran Raman
On Tue, Aug 20, 2013 at 9:35 PM, Xinliang David Li wrote: > Do you need to guard the jump function access with check if > (ipa_node_params_vector.exists ())? I believe it is not necessary since, for example, ipa_analyze_node calls ipa_check_create_node_params that calls create. But I see it is use

Re: [Google] Refine hot caller heuristic

2013-08-29 Thread Easwaran Raman
On Wed, Aug 21, 2013 at 6:47 AM, Teresa Johnson wrote: >> +/* Knob to control hot-caller heuristic. 0 means it is turned off, 1 means >> + it is always applied, and 2 means it is applied only if the footprint is >> + smaller than PARAM_HOT_CALLER_CODESIZE_THRESHOLD. */ >> DEFPARAM (PARAM_INL

Re: [Google] Refine hot caller heuristic

2013-08-29 Thread Xinliang David Li
Ok. Do consider generalize it with 1) more inline hints (how the parameters are used in callee); and 2) more parameter type (such as addr_k, non_null_k, range_k etc you have proposed before) in the future. thanks, David On Thu, Aug 29, 2013 at 11:24 AM, Easwaran Raman wrote: > On Tue, Aug 20,