| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementations.
This assumes that
a) finding the bucket containing the value is LIKELY
b) finding an empty bucket is LIKELY
c) growing the table is UNLIKELY
I also switched the a) and b) cases for SmallPtrSet as we seem to use
the set mostly more for insertion than for checking existence.
In a simple benchmark consisting of 2^21 insertions of 2^20 unique
pointers into a DenseMap or SmallPtrSet a few percent speedup on average,
but nothing statistically significant.
llvm-svn: 230232
|
|
|
|
|
|
|
|
|
|
|
|
| |
private, but non-deleted, move members.
Certain versions of GCC (~4.7) couldn't handle the SFINAE on access
control, but with "= delete" (hidden behind a macro for portability)
this issue is worked around/addressed.
Patch by Agustín Bergé
llvm-svn: 211525
|
|
|
|
|
|
|
|
|
|
|
|
| |
container concept."
This reverts commit r211309.
It looks like it broke some bots:
http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/15563/steps/compile/logs/stdio
llvm-svn: 211328
|
|
|
|
|
|
|
|
| |
container concept.
Patch by Agustín Bergé.
llvm-svn: 211309
|
|
|
|
|
|
| |
to reduce verbosity.
llvm-svn: 205829
|
|
|
|
| |
llvm-svn: 205697
|
|
|
|
|
|
|
|
|
| |
Tombstones and full hash collisions are rare, mark the "empty"
and "no collision" paths as likely. The bug in simplifycfg
that prevented the hints from being picked during selfhost
up was fixed recently :)
llvm-svn: 162874
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringMap suffered from the same bug as DenseMap: when you explicitly
construct it with a small number of buckets, you can arrange for the
tombstone-based growth path to be followed when the number of buckets
was less than '8'. In that case, even with a full map, it would compare
'0' as not less than '0', and refuse to grow the table, leading to
inf-loops trying to find an empty bucket on the next insertion. The fix
is very simple: use '<=' as the comparison. The same fix was applied to
DenseMap as well during its recent refactoring.
Thanks to Alex Bolz for the great report and test case. =]
llvm-svn: 158725
|
|
|
|
|
|
|
| |
- -25% memory usage of the main table on x86_64 (was wasted in struct padding).
- no significant performance change.
llvm-svn: 147294
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringMap was not properly updating NumTombstones after a clear or rehash.
This was not fatal until now because the table was growing faster than
NumTombstones could, but with the previous change of preventing infinite
growth of the table the invariant (NumItems + NumTombstones <= NumBuckets)
stopped being observed, causing infinite loops in certain situations.
Patch by José Fonseca!
llvm-svn: 128567
|
|
|
|
|
|
|
|
| |
Rehash but don't grow when full of tombstones.
Patch by José Fonseca!
llvm-svn: 128565
|
|
|
|
|
|
|
| |
new gcc warning that complains on self-assignments and
self-initializations.
llvm-svn: 122458
|
|
|
|
| |
llvm-svn: 86251
|
|
|
|
| |
llvm-svn: 84344
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Yay for '-'s and simplifications!
- I kept StringMap::GetOrCreateValue for compatibility purposes, this can
eventually go away. Likewise the StringMapEntry Create functions still follow
the old style.
- NIFC.
llvm-svn: 76888
|
|
|
|
| |
llvm-svn: 45418
|
|
|
|
| |
llvm-svn: 35666
|
|
|
|
| |
llvm-svn: 35644
|
|
|
|
|
|
| |
initialized this way, they do not do a malloc to allocate their buckets.
llvm-svn: 35642
|
|
|
|
| |
llvm-svn: 35632
|
|
|
|
| |
llvm-svn: 34185
|
|
|
|
| |
llvm-svn: 34183
|
|
|
|
| |
llvm-svn: 34180
|
|
|
|
| |
llvm-svn: 34179
|
|
strings.
llvm-svn: 34064
|