BitVector had methods for searching for the first and next
set bits, but it did not have analagous methods for finding
the first and next unset bits. This is useful when your ones
and zeros are grouped together and you want to iterate over
ranges of ones and zeros.
Differential Revision: https://reviews.llvm.org/D31802
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299857 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the isMask and isShiftedMask functions to be class methods. They now use the MathExtras.h function for single word size and leading/trailing zeros/ones or countPopulation for the multiword size. The previous implementation made multiple temorary memory allocations to do the bitwise arithmetic operations to match the MathExtras.h implementation.
Differential Revision: https://reviews.llvm.org/D31565
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299362 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is one step to attempt to unify the main APInt interface and the tc functions used by APFloat.
This patch adds a WordType to APInt and uses that in all the tc functions. I've added temporary typedefs to APFloat to alias it to integerPart to keep the patch size down. I'll work on removing that in a future patch.
In future patches I hope to reuse the tc functions to implement some of the main APInt functionality.
I may remove APINT_ from BITS_PER_WORD and WORD_SIZE constants so that we don't have the repetitive APInt::APINT_ externally.
Differential Revision: https://reviews.llvm.org/D31523
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299341 91177308-0d34-0410-b5e6-96231b3b80d8
This removes a parameter from the routine that was responsible for a lot of the issue. It was a bit count that had to be set to the BitWidth of the APInt and would get passed to getLowBitsSet. This guaranteed the call to getLowBitsSet would create an all ones value. This was then compared to (V | (V-1)). So the only shifted masks we detected had to have the MSB set.
The one in tree user is a transform in InstCombine that never fires due to earlier transforms covering the case better. I've submitted a patch to remove it completely, but for now I've just adapted it to the new interface for isShiftedMask.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299273 91177308-0d34-0410-b5e6-96231b3b80d8
Did you know that 0 is a shifted mask? But 0x0000ff00 and 0x000000ff aren't? At least we get 0xff000000 right.
I only see one usage of this function in the code base today and its in InstCombine. I think its protected against 0 being misreported as a mask. I guess we just don't have tests for the missed cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299187 91177308-0d34-0410-b5e6-96231b3b80d8
StringMap's iterators did not support LLVM's
iterator_facade_base, which made it unusable in various
STL algorithms or with some of our range adapters.
This patch makes both StringMapConstIterator as well as
StringMapIterator support iterator_facade_base.
With this in place, it is easy to make an iterator adapter
that iterates over only keys, and whose value_type is
StringRef. So I add StringMapKeyIterator as well, and
provide the method StringMap::keys() that returns a
range that can be iterated.
Differential Revision: https://reviews.llvm.org/D31171
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298436 91177308-0d34-0410-b5e6-96231b3b80d8
There were some issues in the implementation of enumerate()
preventing it from being used in various contexts. These were
all related to the fact that it did not supporter llvm's
iterator_facade_base class. So this patch adds support for that
and additionally exposes a new helper method to_vector() that
will evaluate an entire range and store the results in a
vector.
Differential Revision: https://reviews.llvm.org/D30853
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297633 91177308-0d34-0410-b5e6-96231b3b80d8
We currently have to insert bits via a temporary variable of the same size as the target with various shift/mask stages, resulting in further temporary variables, all of which require the allocation of memory for large APInts (MaskSizeInBits > 64).
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::insertBits() helper method which avoids the temporary memory allocation and masks/inserts the raw bits directly into the target.
Differential Revision: https://reviews.llvm.org/D30780
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297458 91177308-0d34-0410-b5e6-96231b3b80d8
Fix SmallPtrSet::iterator behaviour and creation ReverseIterate is true.
- Any function that creates an iterator now uses
SmallPtrSet::makeIterator, which creates an iterator that
dereferences to the given pointer.
- In reverse-iterate mode, initialze iterator::End with "CurArray"
instead of EndPointer.
- In reverse-iterate mode, the current node is iterator::Buffer[-1].
iterator::operator* and SmallPtrSet::makeIterator are the only ones
that need to know.
- Fix the assertions for reverse-iterate mode.
This fixes the tests Danny B added in r297182, and adds a couple of
others to confirm that dereferencing does the right thing, regardless of
how the iterator was found, and that iteration works correctly from each
return from find.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297234 91177308-0d34-0410-b5e6-96231b3b80d8
This extends an earlier change that did similar for add and sub operations.
With this first patch we lose the fastpath for the single word case as operator&= and friends don't support it. This can be added there if we think that's important.
I had to change some functions in the APInt class since the operator overloads were moved out of the class and can't be used inside the class now. The getBitsSet change collides with another outstanding patch to implement it with setBits. But I didn't want to make this patch dependent on that series.
I've also removed the Or, And, Xor functions which were rarely or never used. I already commited two changes to remove the only uses of Or that existed.
Differential Revision: https://reviews.llvm.org/D30612
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297121 91177308-0d34-0410-b5e6-96231b3b80d8
We currently have methods to set a specified number of low bits, a specified number of high bits, or a range of bits. But looking at some existing code it seems sometimes we want to set the high bits starting from a certain bit. Currently we do this with something like getHighBits(BitWidth, BitWidth - StartBit). Or once we start switching to setHighBits, setHighBits(BitWidth - StartBit) or setHighBits(getBitWidth() - StartBit).
Particularly for the latter case it would be better to have a convenience method like setBitsFrom(StartBit) so we don't need to mention the bit width that's already known to the APInt object.
I considered just making setBits have a default value of UINT_MAX for the hiBit argument and we would internally MIN it with the bit width. So if it wasn't specified it would be treated as bit width. This would require removing the assertion we currently have on the value of hiBit and may not be as readable.
Differential Revision: https://reviews.llvm.org/D30602
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297114 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements getLowBitsSet/getHighBitsSet/getBitsSet in terms of the new setLowBits/setHighBits/setBits methods by making an all 0s APInt and then calling the appropriate set method.
This also adds support to setBits to allow loBits/hiBits to be in the other order to match with getBitsSet behavior.
Differential Revision: https://reviews.llvm.org/D30563
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297112 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There are quite a few places in the code base that do something like the following to set the high or low bits in an APInt.
KnownZero |= APInt::getHighBitsSet(BitWidth, BitWidth - 1);
For BitWidths larger than 64 this creates a short lived APInt with malloced storage. I think it might even call malloc twice. Its better to just provide methods that can set the necessary bits without the temporary APInt.
I'll update usages that benefit in a separate patch.
Reviewers: majnemer, MatzeB, davide, RKSimon, hans
Reviewed By: hans
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30525
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297111 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This makes operator~ take the APInt by value so if it came from a temporary APInt the move constructor will get invoked and it will be able to reuse the memory allocation from the temporary.
This is similar to what was already done for 2s complement negation.
Reviewers: hans, davide, RKSimon
Reviewed By: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30614
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296997 91177308-0d34-0410-b5e6-96231b3b80d8
The current pattern for extract bits in range is typically:
Mask.lshr(BitOffset).trunc(SubSizeInBits);
Which can be particularly slow for large APInts (MaskSizeInBits > 64) as they require the allocation of memory for the temporary variable.
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::extractBits() helper method which avoids the temporary memory allocation.
Differential Revision: https://reviews.llvm.org/D30336
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296272 91177308-0d34-0410-b5e6-96231b3b80d8
The current pattern for extract bits in range is typically:
Mask.lshr(BitOffset).trunc(SubSizeInBits);
Which can be particularly slow for large APInts (MaskSizeInBits > 64) as they require the allocation of memory for the temporary variable.
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::extractBits() helper method which avoids the temporary memory allocation.
Differential Revision: https://reviews.llvm.org/D30336
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296147 91177308-0d34-0410-b5e6-96231b3b80d8
The current pattern for extract bits in range is typically:
Mask.lshr(BitOffset).trunc(SubSizeInBits);
Which can be particularly slow for large APInts (MaskSizeInBits > 64) as they require the allocation of memory for the temporary variable.
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::extractBits() helper method which avoids the temporary memory allocation.
Differential Revision: https://reviews.llvm.org/D30336
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296141 91177308-0d34-0410-b5e6-96231b3b80d8
The current pattern for setting bits in range is typically:
Mask |= APInt::getBitsSet(MaskSizeInBits, LoPos, HiPos);
Which can be particularly slow for large APInts (MaskSizeInBits > 64) as they require the allocation memory for the temporary variable.
This is one of the key compile time issues identified in PR32037.
This patch adds the APInt::setBits() helper method which avoids the temporary memory allocation completely, this first implementation uses setBit() internally instead but already significantly reduces the regression in PR32037 (~10% drop). Additional optimization may be possible.
I investigated whether there is need for APInt::clearBits() and APInt::flipBits() equivalents but haven't seen these patterns to be particularly common, but reusing the code would be trivial.
Differential Revision: https://reviews.llvm.org/D30265
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296102 91177308-0d34-0410-b5e6-96231b3b80d8
This commit provides `zip_{first,shortest}` with the standard member types and
methods expected of iterators (e.g., `difference_type`), in order for zip to be
used with other adaptors, such as `make_filter_range`.
Support for reverse iteration has also been added.
Differential Revision: https://reviews.llvm.org/D30246
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296036 91177308-0d34-0410-b5e6-96231b3b80d8
Add explicit conversions between forward and reverse ilist iterators.
These follow the conversion conventions of std::reverse_iterator, which
are off-by-one: the newly-constructed "reverse" iterator dereferences to
the previous node of the one sent in. This has the benefit of
converting reverse ranges in place:
- If [I, E) is a valid range,
- then [reverse(E), reverse(I)) gives the same range in reverse order.
ilist_iterator::getReverse() is unchanged: it returns a reverse iterator
to the *same* node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294349 91177308-0d34-0410-b5e6-96231b3b80d8
Triple::objectFormat defaults to an Elf format.
Changing objectFormat to Elf doesn't make any difference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294104 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: As per title. I ran into that limitation of the API doing some other work, so I though that'd be a nice addition.
Reviewers: jroelofs, compnerd, majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29503
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294063 91177308-0d34-0410-b5e6-96231b3b80d8
