It's nice to be able to find the next set bit, but often you have a clump of them and you want to find where they stop, i.e. by locating the next unset bit. This patch does that.
Details
Diff Detail
Event Timeline
Not really in the scope of this change, but, since BitVector has these STL-like methods, 'twould be nice if there were a BitVector::npos analogous to std::basic_string::npos rather than having all the users of the class have to hardcode the magic value or make vague checks like >= 0.
I realize that these methods are returning an int rather than a size_type like the corresponding methods on strings. Still, magic sentinel values are magic sentinel values, and the usage would be more consistent.
llvm/include/llvm/ADT/BitVector.h | ||
---|---|---|
206 | Remind me what endianness we use ? | |
220 | It would be nice to factor this out with the copy above the loop into a little helper function that takes and Bits. |
Fixed an issue where find_first_unset() was returning BV.size() if all bits were set, and added a unit test for that case.
llvm/include/llvm/ADT/BitVector.h | ||
---|---|---|
206 | Yea, we had this same confusion last time. Didn't you write this thing! :) If you want the 0'th bit, it's the rightmost bit. So using an example, say Prev is 4, which means you've got something like XXXXXXXXXXXXYYYY where the Y's are the bits you don't care about, and the rightmost X is the bit you want to start searching from, leftwards. So, we set all the Y bits to 1 by producing the bit pattern 10000 and then subtracting 1, and then or that in. Then we count the number of trailing 1s. The check below that looks if there is at least one zero-bit, and if there is it finds the last one by counting the number of trailing 1s. But the confusion doesn't stop there, because if your word size is, say, 64 bits, but your BitVector only represents 10 bits, then then the left most 54 bits are going to be 0 even though they are out of bounds. So we need the Result < size() check there as well. |
Remind me what endianness we use ?
I would have expected it to simply be << some number of bits, then countleadingones.
It looks reversed, so i'm assuming i'm thinking the wrong way around :)