Note that there's a rather annoying feature of x86 that the bsf and bsr instructions leave the destination register as is (undefined, but in practice whatever was there before) when the argument register is zero. The upshot is that unless the user expresses at the LLVM level that they don't care about this edge case, or LLVM can prove that it can't happen, the generated code is annoyingly long. Thus, using the leading_ones function here is not the most efficient.
On Sat, Aug 13, 2016 at 11:10 AM, Steven G. Johnson <[email protected]> wrote: > > > On Saturday, August 13, 2016 at 9:22:14 AM UTC-4, jw3126 wrote: >> >> Sorry my question was confusing. What I want is a function that behaves >> as follows on bittypes: >> >> *0*0101101 -> 0 >> *0*1110101 -> 0 >> *0*1011011 -> 0 >> *1*0011101 -> 1 >> *1*1010001 -> 1 >> *1*0110111 -> 1 >> > > Normally to compute this function you would just check whether the > bitwise-and with 10000000 is nonzero. e.g. > > firstbit(n::Union{UInt8,Int8}) = (n & 0x80) != 0 > firstbit(n::Union{UInt16,Int16}) = (n & 0x8000) != 0 > firstbit(n::Union{UInt32,Int32}) = (n & 0x80000000) != 0 > firstbit(n::Union{UInt64,Int64}) = (n & 0x8000000000000000) != 0 > firstbit(n::Union{UInt128,Int128}) = (n & 0x80000000000000000000000000000000) > != 0 > firstbit(n::Integer) = leading_ones(n) > 0 >
