[PATCH] D30336: [APInt] Add APInt::extractBits() method to extract APInt subrange
Hans Wennborg via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 24 10:25:21 PST 2017
hans added inline comments.
================
Comment at: lib/Support/APInt.cpp:624
+ assert(bitPosition < BitWidth && (numBits + bitPosition) <= BitWidth &&
+ "Illegal bit extraction");
+
----------------
This is very nit-picky, but I find `numBits > 0` much more natural than `0 < numBits`.
And I'd suggest splitting up the second assert into two, to make it clearer what went wrong if it fires.
================
Comment at: lib/Support/APInt.cpp:628
+ if (isSingleWord())
+ return APInt(numBits, VAL >> loBit);
+
----------------
For the single-word case we know bitPosition is in the first word, so there's no need for the remainder operation in `whichBit`. I'd suggest moving the if-statement before computing loBit, and just using bitPosition in the shift.
================
Comment at: lib/Support/APInt.cpp:645
+ uint64_t *pDst = Result.pVal;
+ for (unsigned word = loWord; word < hiWord; ++word, ++pDst) {
+ uint64_t w0 = pVal[word + 0];
----------------
I'm not sure this loop is correct. It will never set `Result.pVal[hiWord]`?
The only test case I see that hits this loop is `EXPECT_EQ(-8388481, i256.extractBits(128, 1).getSExtValue());`
In that one, the result is computed from three words, but indeed fits into two words.
But what if it didn't -- what about `i256.extractBits(129, 1)`?
================
Comment at: unittests/ADT/APIntTest.cpp:1441
+
+ APInt i256(256, -16776961 /* 0xFFFFFFFFFFFFFFFFFFFFFFFFFF0000FF */, true);
+ EXPECT_EQ(255, i256.extractBits(16, 0));
----------------
Would it be possible to use hex constants here and in the expectations somehow? Especially for the last one, it's hard to see what the expected result should be..
Repository:
rL LLVM
https://reviews.llvm.org/D30336
More information about the llvm-commits
mailing list