[PATCH] D122234: [clang] Link libbitint for large division of _BitInt; increase max _BitInt size

Erich Keane via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 22 09:39:38 PDT 2022


erichkeane added inline comments.


================
Comment at: clang/lib/Lex/LiteralSupport.cpp:1232
 
+  if (llvm::isPowerOf2_32(radix)) {
+    unsigned BitsPerDigit = llvm::Log2(radix);
----------------
mgehre-amd wrote:
> erichkeane wrote:
> > Can you explain what is going on here?  This isn't at all obvious to me.
> When I adapted the test case  clang/test/Lexer/bitint-constants.c https://reviews.llvm.org/D122234#change-GjEFAAe2jzfe to test literals with 2097152 hex digits, clang spend minutes in the code below to try to turn that literal into a ApInt of 8388608 bits.
> 
> That is because the code below does a generic `Val *= Radix` and `Val += Digit`. The `Val *= Radix` is very slow on a ApInt with 8388608 bits, and it's also not needed when
> we know that `Radix` is a power of two. Then one can just copy the bits from each Digit into the right position in Val.
> 
> If the integer literals can just be 128 bits or something, it doesn't matter, but now we need to support really big integer literals with having increased the limit on _BitInt width.
Hmm, so this is only really an issue with base-10 integer values?  Is the same 'clang spent minutes in...' still a problem for base 10 literals?  It would be unfortunate if we cannot just fix that.

Additionally, I'd like some comment to explain this, it isn't particularly clear what it is doing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122234/new/

https://reviews.llvm.org/D122234



More information about the cfe-commits mailing list