[llvm] r184590 - Revert "BlockFrequency: Saturate at 1 instead of 0 when multiplying a frequency with a branch probability."

[Jakob Stoklund Olesen]

On Jun 24, 2013, at 10:26 AM, Benjamin Kramer <benny.kra at gmail.com> wrote:

> It asserts that frequencies going out of a loop are less or equal to the frequency that went into the loop. This can be easily broken when saturating to 1. You can have many blocks that have a zero frequency due to underflows; If you saturate at 1 and take the sum the result becomes larger. Over the whole function this can yield values that are way off from what we really wanted.
> 
> This seems to be a fundamental problem of representing block frequencies as a fixed point number. We'll probably need a more flexible way. Chandler suggested to store it as a ratio and rescale when necessary to minimize precision loss.

A ratio has the same dynamic range per bit as a fixpoint number. It will underflow to zero just as quickly, and behave as badly when it happens. You can shift the dynamic range around, of course, but that just gives you the same problems in the high end.

For any representation, we'll need reasonable behavior in both ends of the range, even if we go with floating point.

Fixpoint numbers are like floating point numbers, they represent an approximation to real numbers. Because they are approximations, they may not have exactly the same mathematical properties as integers. In this case, the block frequency computation seems to assert that some kind of triangle equality holds. It shouldn’t assert that without allowing for some imprecision.

I am proposing that we use a number representation with non-sticky saturation in both ends of the representable range. We already have that in the high end: Calculations saturate at UINT64_MAX, but unlike IEEE infinity, they don’t stay saturated when multiplied by fractions < 1.

We need the same behavior at the low end: Saturate to 1 instead of 0. This limit is non-sticky so multiplying it by a fraction > 1 can still give you a larger number.

Thanks,
/jakob