Consider fully replacing BBF_RUN_RARELY with the weight of 0

[SingleAccretion]

I see that most code clearing this flag is doing the moral equivalent of the following:

block->bbWeight = weight;
if (weight > 0)
{
    block->bbFlags &= ~BBF_RUN_RARELY;
}

Perhaps it would be feasible to avoid writing this code and just use bbWeight == 0.0f (bbSetRunRarely/isRunRarely) everywhere instead?

cc @AndyAyersMS

Edit: label addition was not intended :(.

category:cq
theme:profile-feedback

[AndyAyersMS]

BBF_RUN_RARELY gets set even when we don't have profile data, eg for things like BBJ_THROW blocks.

My ambition is that we always have some form of profile data flowing around, even if we have to synthesize it via heuristics. Once we get to that point, your suggestion (or something similar) makes total sense.

[SingleAccretion]

BBF_RUN_RARELY gets set even when we don't have profile data, eg for things like BBJ_THROW blocks.

I see. My thinking was we'd indicate the fact that that the weight (profile-derived or synthetic) is missing by some sentinel value as well (e. g. -1), but if the plan is to always have valid weights, than this change should indeed wait.

[AndyAyersMS]

The plan is to always have weights, yes. In the scheme I'm envisioning, zero weights would have special meaning. Synthesis would only produce zeros for things that are truly always rare, like throws.

When we have true profile data, the plan is to blend in a little bit of synthesis data so that we're not overfitting our optimizations to the observed behavior (in a perhaps ideal world if a profile-optimized program fell "off trace" too often we would reoptimize, but we're a ways off from things like that). So even if a block ends up unprofiled it will have a small nonzero weight.

I expect at that point the notion of rare will split into "truly rare" and "cold" and we'll have to sort out conditions for the optimizations currently gated by rare.