arbitrary range of bits embedded in the middle of another bignum.
This kind of operation is desirable in many cases of software
floating point, e.g. converting bignum integers to floating point
numbers of fixed precision (you want to extract the precision most
significant bits).
Elsewhere, add an assertion, and exit the shift functions early if
the shift count is zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42745 91177308-0d34-0410-b5e6-96231b3b80d8
part widths. Also, return the number of parts actually required to
hold the result's value.
Remove an over-cautious condition from rounding of float->hex conversion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42669 91177308-0d34-0410-b5e6-96231b3b80d8
bit width instead of number of words allocated, which
makes it actually work for int->APF conversions.
Adjust callers. Add const to one of the APInt constructors
to prevent surprising match when called with const
argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42210 91177308-0d34-0410-b5e6-96231b3b80d8
double from some of the many places in the optimizers
it appears, and do something reasonable with x86
long double.
Make APInt::dump() public, remove newline, use it to
dump ConstantSDNode's.
Allow APFloats in FoldingSet.
Expand X86 backend handling of long doubles (conversions
to/from int, mostly).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41967 91177308-0d34-0410-b5e6-96231b3b80d8
two's complement bignum arithmetic. They could be used to
implement much of APInt, but the idea is they are enough to
implement APFloat as well, which the current APInt interface
is not suited for.
Patch by Neil Booth!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41124 91177308-0d34-0410-b5e6-96231b3b80d8
types:
1. Functions to compute div/rem at the same time.
2. Further assurance that an APInt with 0 bitwidth cannot be constructed.
3. Left and right rotate operations.
4. An exactLogBase2 function which requires an exact power of two or it
returns -1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37025 91177308-0d34-0410-b5e6-96231b3b80d8
and shifting down without regard for the bitwidth of the APInt can lead
to incorrect initialization values. Instead, check for the word size case
(to avoid undef results from shift) and then do (1 << loBitsSet) - 1
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35344 91177308-0d34-0410-b5e6-96231b3b80d8
illegal. Instead do the 0 valued construction for the user. This is because
the caller may not know (or care to check) that the number of bits set is
zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35315 91177308-0d34-0410-b5e6-96231b3b80d8
they should have used the uint64_t constructor. This avoids causing
undefined results via shifts by the word size when the bit width is an
exact multiple of the word size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35313 91177308-0d34-0410-b5e6-96231b3b80d8
already covered by getLowBitsSet (i.e. when loBits==0). Consequently, remove
the default value for loBits and reorder the arguments to the more natural
loBits, hiBits order. This makes it more clear that this function is for bit
groups in the middle of the bit width and not towards one end or the other.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35312 91177308-0d34-0410-b5e6-96231b3b80d8
