original and new instruction. A slight performance hit with ostringstream
but it is only for debug.
Also, clean up an uninitialized variable warning noticed in a release build.
llvm-svn: 35358
Fix SingleSource/Regression/C/2003-05-21-UnionBitFields.c by changing a
getHighBitsSet call to getLowBitsSet call that was incorrectly converted
from the original lshr constant expression.
llvm-svn: 35348
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
llvm-svn: 35344
Remove a use of getLowBitsSet that caused the mask used for replacement of
shl/lshr pairs with an AND instruction to be computed incorrectly. Its not
clear exactly why this is the case. This solves the disappearing shifts
problem, but it doesn't fix Regression/C/2003-05-21-UnionBitFields. It
seems there is more going on.
llvm-svn: 35342
* Don't assume shift amounts are <= 64 bits
* Avoid creating an extra APInt in SubOne and AddOne by using -- and ++
* Add another use of getLowBitsSet
* Convert a series of if statements to a switch
llvm-svn: 35339
using the facilities of APInt. While this duplicates a tiny fraction of
the constant folding code, it also makes the code easier to read and
avoids large ConstantExpr overhead for simple, known computations.
llvm-svn: 35335
* Convert the last use of a uint64_t that should have been an APInt.
* Change ComputeMaskedBits to have a const reference argument for the Mask
so that recursions don't cause unneeded temporaries. This causes temps
to be needed in other places (where the mask has to change) but this
change optimizes for the recursion which is more frequent.
* Remove two instances of &ing a Mask with getAllOnesValue. Its not
needed any more because APInt is accurate in its bit computations.
* Start using the getLowBitsSet and getHighBits set methods on APInt
instead of shifting. This makes it more clear in the code what is
going on.
llvm-svn: 35321
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.
llvm-svn: 35315
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.
llvm-svn: 35313
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.
llvm-svn: 35312
Dale Johannesen