This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.
This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222334 91177308-0d34-0410-b5e6-96231b3b80d8
Various places in LLVM assume that container size and count are unsigned
and do not use the container size_type. Therefore they break compilation
(or possibly executation) for LP64 systems where size_t is 64 bit while
unsigned is still 32 bit.
If we'll ever that many items in the container size_type could be made
size_t for a specific containers after reviweing its other uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211353 91177308-0d34-0410-b5e6-96231b3b80d8
only 1/0 result like std::set. Some of the LLVM ADT already return unsigned
count(), while others still return bool count().
In continuation to r197879, this patch modifies DenseMap, DenseSet,
ScopedHashTable, ValueMap:: count() to return size_type instead of bool,
1 instead of true and 0 instead of false.
size_type is typedef-ed locally within each class to size_t.
http://reviews.llvm.org/D4018
Reviewed by dblaikie.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211350 91177308-0d34-0410-b5e6-96231b3b80d8
iteration. This alows the majority of operations to be performed without
encoding a specific small size. It follows the model of
SmallVectorImpl<T>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200688 91177308-0d34-0410-b5e6-96231b3b80d8
'SmallPtrSetImplBase'. This more closely matches the organization of
SmallVector and should allow introducing a SmallPtrSetImpl which serves
the same purpose as SmallVectorImpl: isolating the element type from the
particular small size chosen. This in turn allows a lot of
simplification of APIs by not coding them against a specific small size
which is rarely needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200687 91177308-0d34-0410-b5e6-96231b3b80d8
where it's only bool-like 1/0 result like std::set.count().
Some of the LLVM ADT already return unsigned count(), while
others return bool count().
This patch modifies SmallPtrSet, SmallSet, SparseSet count()
to return unsigned instead of bool:
1 instead of true
0 instead of false
More ADT to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197879 91177308-0d34-0410-b5e6-96231b3b80d8
Enhance the tests to actually require moves in C++11 mode, in addition
to testing the moved-from state. Further enhance the tests to cover
copy-assignment into a moved-from object and moving a large-state
object. (Note that we can't really test small-state vs. large-state as
that isn't an observable property of the API really.) This should finish
addressing review on r195239.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195261 91177308-0d34-0410-b5e6-96231b3b80d8
Somehow, this ADT got missed which is moderately terrifying considering
the efficiency of move for it.
The code to implement move semantics for it is pretty horrible
currently but was written to reasonably closely match the rest of the
code. Unittests that cover both copying and moving (at a basic level)
added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195239 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 617330909f0c26a3f2ab8601a029b9bdca48aa61.
It broke the bots:
/home/clangbuild2/clang-ppc64-2/llvm.src/unittests/ADT/SmallVectorTest.cpp:150: PushPopTest
/home/clangbuild2/clang-ppc64-2/llvm.src/unittests/ADT/SmallVectorTest.cpp:118: Failure
Value of: v[i].getValue()
Actual: 0
Expected: value
Which is: 2
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178334 91177308-0d34-0410-b5e6-96231b3b80d8
DenseMap's hash function uses slightly more entropy and reduces hash collisions
significantly. I also experimented with Hashing.h, but it didn't gave a lot of
improvement while being much more expensive to compute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154996 91177308-0d34-0410-b5e6-96231b3b80d8
This currently assumes that both sets have the same SmallSize to keep the implementation simple,
a limitation that can be lifted if someone cares.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152143 91177308-0d34-0410-b5e6-96231b3b80d8
replaced by a bigger array in SmallPtrSet (by overridding it), instead just use a
pointer to the start of the storage, and have SmallPtrSet pass in the value to use.
This has the disadvantage that SmallPtrSet becomes bigger by one pointer. It has
the advantage that it no longer uses tricky C++ rules, and is clearly correct while
I'm not sure the previous version was. This was inspired by g++-4.6 pointing out
that SmallPtrSetImpl was writing off the end of SmallArray, which it was. Since
SmallArray is replaced with a bigger array in SmallPtrSet, the write was still to
valid memory. But it was writing off the end of the declared array type - sounds
kind of dubious to me, like it sounded dubious to g++-4.6. Maybe g++-4.6 is wrong
and this construct is perfectly valid and correctly compiled by all compilers, but
I think it is better to avoid the whole can of worms by avoiding this construct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107285 91177308-0d34-0410-b5e6-96231b3b80d8
SmallArray[SmallSize] in the SmallPtrSetIteratorImpl, and this is
one off the end of the array. For those who care, right now gcc
warns about writing off the end because it is confused about the
declaration of SmallArray as having length 1 in the parent class
SmallPtrSetIteratorImpl. However if you tweak code to unconfuse
it, then it still warns about writing off the end of the array,
because of this buffer overflow. In short, even with this fix
gcc-4.6 will warn about writing off the end of the array, but now
that is only because it is confused.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107200 91177308-0d34-0410-b5e6-96231b3b80d8
contents of the set were small, deallocate and shrink the set. This
avoids having us to memset as much data, significantly speeding up
some pathological cases. For example, this speeds up the verifier
from 0.3899s to 0.0763 (5.1x) on the testcase from PR1432 in a
release build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40837 91177308-0d34-0410-b5e6-96231b3b80d8
