Fixes #141098
Added APInt::clearBits(unsigned loBit, unsigned hiBit) that clears bits within a certain range. Fixes #136550 --------- Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk>
Remove erroneous extra semicolon in: https://github.com/llvm/llvm-project/pull/122788 Co-authored-by: ImanHosseini <imanhosseini.17@gmail.com>
I am trying to calculate power function for APFloat, APInt to constant fold vector reductions: https://github.com/llvm/llvm-project/pull/122450 I need this utility to fold N `mul`s into power. --------- Co-authored-by: ImanHosseini <imanhosseini.17@gmail.com> Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>
Use an arithmetic shift for the last word copy when BitShift!=0. This avoids an explicit sign extend after the shift.
The purpose is to save an extra memset in both cases: 1. When `int64_t(val) < 0`, zeroing out is redundant as the subsequent for-loop will initialize to `val .. 0xFFFFF ....`. Instead we should only create an uninitialized buffer, and transform the slow for-loop into a memset to initialize the higher words to `0xFF`. 2. In the other case, first we create an uninitialized array (`new int64_t[]`) and _then_ we zero it out with `memset`. But this can be combined in one operation with `new int64_t[]()`, which default-initializes the array. On one example where use of APInt was heavy, this improved compile time by 1%.
If the uint64_t constructor is used, assert that the value is actually a signed or unsigned N-bit integer depending on whether the isSigned flag is set. Provide an implicitTrunc flag to restore the previous behavior, where the argument is silently truncated instead. In this commit, implicitTrunc is enabled by default, which means that the new assertions are disabled and no actual change in behavior occurs. The plan is to flip the default once all places violating the assertion have been fixed. See #80309 for the scope of the necessary changes. The primary motivation for this change is to avoid incorrectly specified isSigned flags. A recurring problem we have is that people write something like `APInt(BW, -1)` and this works perfectly fine -- until the code path is hit with `BW > 64`. Most of our i128 specific miscompilations are caused by variants of this issue. The cost of the change is that we have to specify the correct isSigned flag (and make sure there are no excess bits) for uses where BW is always <= 64 as well.
In order to guarantee that extracting 64 bits doesn't require more than 2 words, the word size would need to be 64 bits or more. If the word size was smaller than 64, like 32, you may need to read 3 words to get 64 bits.