[llvm] r197272 - [block-freq] Add the method APInt::nearestLogBase2().

[Michael Gottesman]

r199610. Also I found another potential bug when we combine together the zero/non-zero case like I did, if we have an integer with a bit width large enough to be > UINT32_MAX, we will get the wrong answer. I added it in as a test in said commit. This additionally exposed a bug when we construct large APInts [I guess today I am a bug hunter! = )].

Michael

On Dec 15, 2013, at 10:39 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:

> On 2013 Dec 15, at 20:41, Michael Gottesman <mgottesman at apple.com> wrote:
> 
>> On Dec 15, 2013, at 2:44 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> 
>>> I thought of another degenerate case, and unfortunately I think the
>>> current code gets the wrong answer:
>>> 
>>> - APInt(1, 1).nearestLogBase2() == 0 // lg(1) should give 0, not 1.
>> 
>> This is incorrect since log2 is not a well defined operation in Z/Z_1. If one defines log2(x) as the largest N such that 2^N < x then since in Z/Z_1, 2^N = 0^N, N could be any number. In reality we should probably add in an assertion to make sure that the routines are only called if the BitWidth is > 1.
> 
> I’m not convinced that lg(1) is undefined; whether 2 itself is
> representable is irrelevant.  Even if I’m wrong, the following
> would be surprising:
> 
>   x.logBase2()        => 0
>   x.ceilLogBase2()    => 0
>   x.nearestLogBase2() => 1 ???
> 
> AFAICT, countLeadingZeros() hits at least two branches before
> calling __builtin_clz, so the micro-optimization won't give
> much benefit in practice anyway.