On Fri, Aug 5, 2011 at 3:24 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> > >> > In a way I like the current scheme since it is simple and extending it >> > should IMO have some good reason. We could refine -Os behaviour without >> > changing current predicates to optimize for speed in >> > a) functions declared as "hot" by user and BBs in them that are not proved >> > cold. >> > b) based on profile feedback - i.e. we could have two thresholds, BBs with >> > very arge counts wil be probably hot, BBs in between will be maybe >> > hot/normal and BBs with low counts will be cold. >> > This would probably motivate introduction of probably_hot predicate that >> > summarize the above. >> >> Introducing a new 'probably_hot' will be very confusing -- unless you >> also rename 'maybe_hot', but this leads to finer grained control: >> very_hot, hot, normal, cold, unlikely which can be hard to use. The >> three state partition (not counting exec_once) seems ok, but > > OK, I also preffer to have fewer stages than more ;) >> >> 1) the unlikely state does not have controllable parameter > > Well, it is defined as something that is not likely to be executed, so the > requirement > on count to be less than 1/(number_of_test_runs*2) is very natural and don't > seem > to need to be tuned.
Ok, so it is defined to be different from 'rarely-executed' case. However rarely-executed seems more general and can perhaps be used in place of unlikely case. If there are situation that applies only to 'unlikely', they can be split apart. David
