Re: [Patch] Handle profile counts truncated to 0 in coldness test

> > As noted above, the change to avoid the RDIV by runs decreases the > effect of the min_run_ratio (now unlikely_count_fraction) in half. So > we really need to increase this parameter to 32 to compare to what the > old version of the code was doing. > > Indeed, using 32 does fix the same set o

Re: [Patch] Handle profile counts truncated to 0 in coldness test

Ping on this one since the new param would be useful in the other profile related patch I'm working on (the one to handle the dropped profile counts in tree-profile). Thanks, Teresa On Thu, Oct 10, 2013 at 2:35 PM, Teresa Johnson wrote: > On Mon, Oct 7, 2013 at 10:45 PM, Teresa Johnson wrote: >

Re: [Patch] Handle profile counts truncated to 0 in coldness test

On Mon, Oct 7, 2013 at 10:45 PM, Teresa Johnson wrote: > On Sun, Oct 6, 2013 at 6:43 AM, Jan Hubicka wrote: >>> 2013-10-03 Teresa Johnson >>> >>> * params.def (PARAM_MIN_HOT_RUN_RATIO): New parameter. >> >> I would not mention HOT in the parameter name. Blocks are >> hot/normal/unlik

Re: [Patch] Handle profile counts truncated to 0 in coldness test

On Mon, Oct 7, 2013 at 10:49 PM, Teresa Johnson wrote: > On Sun, Oct 6, 2013 at 6:51 AM, Jan Hubicka wrote: >>> The second part ensures that frequencies are correctly updated after >>> inlining. The problem is that after inlining the frequencies were >>> being recomputed directly from the corresp

Re: [Patch] Handle profile counts truncated to 0 in coldness test

On Sun, Oct 6, 2013 at 6:51 AM, Jan Hubicka wrote: >> The second part ensures that frequencies are correctly updated after >> inlining. The problem is that after inlining the frequencies were >> being recomputed directly from the corresponding bb counts in >> rebuild_frequencies. If the counts had

Re: [Patch] Handle profile counts truncated to 0 in coldness test

On Fri, Oct 4, 2013 at 8:54 AM, Xinliang David Li wrote: > On Thu, Oct 3, 2013 at 10:15 PM, Teresa Johnson wrote: >> This patch handles the fact that small profile count values sometimes >> get truncated down to 0 during updates due to integer arithmetic. This >> causes sub-optimal function split

Re: [Patch] Handle profile counts truncated to 0 in coldness test

On Sun, Oct 6, 2013 at 6:43 AM, Jan Hubicka wrote: >> 2013-10-03 Teresa Johnson >> >> * params.def (PARAM_MIN_HOT_RUN_RATIO): New parameter. > > I would not mention HOT in the parameter name. Blocks are hot/normal/unlikely > and we HOT_BB_FREQUENCY_FRACTION. > > So perhaps UNLIKELY_BB_

Re: [Patch] Handle profile counts truncated to 0 in coldness test

> The second part ensures that frequencies are correctly updated after > inlining. The problem is that after inlining the frequencies were > being recomputed directly from the corresponding bb counts in > rebuild_frequencies. If the counts had been truncated to 0, then the > recomputed frequencies

Re: [Patch] Handle profile counts truncated to 0 in coldness test

> 2013-10-03 Teresa Johnson > > * params.def (PARAM_MIN_HOT_RUN_RATIO): New parameter. I would not mention HOT in the parameter name. Blocks are hot/normal/unlikely and we HOT_BB_FREQUENCY_FRACTION. So perhaps UNLIKELY_BB_COUNT_FRACTION with an explanation that it is relative to numb

Re: [Patch] Handle profile counts truncated to 0 in coldness test

On Thu, Oct 3, 2013 at 10:15 PM, Teresa Johnson wrote: > This patch handles the fact that small profile count values sometimes > get truncated down to 0 during updates due to integer arithmetic. This > causes sub-optimal function splitting under > -freorder-blocks-and-partition. > > The first part

[Patch] Handle profile counts truncated to 0 in coldness test

This patch handles the fact that small profile count values sometimes get truncated down to 0 during updates due to integer arithmetic. This causes sub-optimal function splitting under -freorder-blocks-and-partition. The first part fixes the logic in probably_never_executed that looks at the bb fr