Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are
predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`.
`LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with
`LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake /
autoconf build system.
Reviewers: chandlerc, dexonsmith, rnk, zturner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8351
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233310 91177308-0d34-0410-b5e6-96231b3b80d8
To complement getSplat. This is more general than the binary
decomposition method as it also handles non-pow2 splat sizes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233195 91177308-0d34-0410-b5e6-96231b3b80d8
It's not intended to be polymorphically deleted. Make FoldingSet
and ContextualFoldingSet final to avoid noise from -Wnon-virtual-dtor.
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232922 91177308-0d34-0410-b5e6-96231b3b80d8
Modern libc's have an SSE version of memchr which is a lot faster than our
hand-rolled version. In the past I was reluctant to use it because Darwin's
memchr used a naive ridiculously slow implementation, but that has been fixed
some versions ago.
Should have zero functional impact.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232898 91177308-0d34-0410-b5e6-96231b3b80d8
ARMv6K is another layer between ARMV6 and ARMV6T2. This is the LLVM
side of the changes.
ARMV6 family LLVM implementation.
+-------------------------------------+
| ARMV6 |
+----------------+--------------------+
| ARMV6M (thumb) | ARMV6K (arm,thumb) | <- From ARMV6K and ARMV6M processors
+----------------+--------------------+ have support for hint instructions
| ARMV6T2 (arm,thumb,thumb2) | (SEV/WFE/WFI/NOP/YIELD). They can
+-------------------------------------+ be either real or default to NOP.
| ARMV7 (arm,thumb,thumb2) | The two processors also use
+-------------------------------------+ different encoding for them.
Patch by Vinicius Tinti.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232468 91177308-0d34-0410-b5e6-96231b3b80d8
Messed it up because I didn't realize there were two different iterators
here (& clearly didn't build any of this... ) - still seems easier to
just use the injected class name than introduce a self typedef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232462 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies code quite a bit and brings the iterators closer to
C++'s iterator concept. No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232319 91177308-0d34-0410-b5e6-96231b3b80d8
Sorting them is obviously a noop and we can skip the libc call. This is
surprisingly common in clang. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232265 91177308-0d34-0410-b5e6-96231b3b80d8
Currently IntervalMap would assert when used with keys bigger than host
pointers. This patch uses the AlignedCharArrayUnion functionality to
overcome that limitation.
Differential Revision: http://reviews.llvm.org/D8268
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232079 91177308-0d34-0410-b5e6-96231b3b80d8
CloudABI is a POSIX-like runtime environment built around the concept of
capability-based security. More details:
https://github.com/NuxiNL/cloudlibc
CloudABI uses its own ELFOSABI number. This number has been allocated by
the maintainers of ELF a couple of days ago.
Reviewed by: echristo
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231681 91177308-0d34-0410-b5e6-96231b3b80d8
This patch was landed in r231035 and reverted because it was buggy.
This is fixed version of the same change.
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Reviewers: dexonsmith, dberlin, ruiu, chandlerc
Reviewed By: chandlerc
Subscribers: yaron.keren, chandlerc, llvm-commits
Differential Revision: http://reviews.llvm.org/D7931
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231125 91177308-0d34-0410-b5e6-96231b3b80d8
Without this, use of this copy ctor is deprecated in C++11 due to the
presence of a user-declared dtor.
Marking the class final is just a little extra security that there are
no further derived classes that may then end up using the intermediate
base class's copy assignment operator and cause slicing to occur.
I didn't bother marking the other (non-test) base class final, since it
has reference members so it won't have any implicit assignment operators
anyway. Open to ideas on that, though.
We probably want a warning about use of a slicing assignment operator,
then I wouldn't worry so much about marking the class as final.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231114 91177308-0d34-0410-b5e6-96231b3b80d8
I tried making these private & friended to the BitVector, but that
didn't work - there's one use of BitVector::reference in Clang that
actually copies it into a local variable & uses it from there, rather
than just using the result of op[] in a temporary expression.
Whether or not this is desired is debatable (we could just fix that one
use in Clang) & it's not clear which way the C++ standard falls on this
for std::bitset's reference type (it has the same bug at least in
libstdc++, but Clang's -Wdeprecated doesn't flag it, because it's in a
standard header)
While it was only BitVector::reference's copy ctor that was referenced
by user code, I made SmallBitVector::reference's copy ctor public too,
for consistency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231099 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Reviewers: dexonsmith, dberlin, ruiu, chandlerc
Reviewed By: chandlerc
Subscribers: yaron.keren, chandlerc, llvm-commits
Differential Revision: http://reviews.llvm.org/D7931
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231035 91177308-0d34-0410-b5e6-96231b3b80d8
This has the nice property of compiling down to memcmp when feasible. An empty
ArrayRef can have a nullptr in its Data field. I didn't find anything in the
standard speaking against std::equal(nullptr, nullptr, nullptr) begin valid but
MSVC asserts. The way libstdc++ lowers std::equal down to memcmp also makes
invoking std::equal with a nullptr undefined behavior so checking is the only
way to be safe.
The extra check doesn't cost us perf either because we're essentially peeling
the loop header away from the rotated loop.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230920 91177308-0d34-0410-b5e6-96231b3b80d8
With initializer lists there is a really neat idiomatic way to write
this, 'ArrayRef.equals({1, 2, 3, 4, 5})'. Remove the equal method which
always had a hard limit on the number of arguments. I considered
rewriting it with variadic templates but that's not really a good fit
for a function with homogeneous arguments.
'ArrayRef == {1, 2, 3, 4, 5}' would've been even more awesome, but C++11
doesn't allow init lists with binary operators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230907 91177308-0d34-0410-b5e6-96231b3b80d8
This looks ridiculous but SmallVector's realloc tricks really help with
large vectors of PODs, such as our virtreg IndexedMap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230866 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230232 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces a new mechanism that allows IR modules to co-operatively
build pointer sets corresponding to addresses within a given set of
globals. One particular use case for this is to allow a C++ program to
efficiently verify (at each call site) that a vtable pointer is in the set
of valid vtable pointers for the class or its derived classes. One way of
doing this is for a toolchain component to build, for each class, a bit set
that maps to the memory region allocated for the vtables, such that each 1
bit in the bit set maps to a valid vtable for that class, and lay out the
vtables next to each other, to minimize the total size of the bit sets.
The patch introduces a metadata format for representing pointer sets, an
'@llvm.bitset.test' intrinsic and an LTO lowering pass that lays out the globals
and builds the bitsets, and documents the new feature.
Differential Revision: http://reviews.llvm.org/D7288
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230054 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes an error introduced in r228934 where None was converted to
an int instead of the int being converted to an Optional as intended.
We make that sort of mistake a compile error by changing NoneType into
a scoped enum.
Finally, provide a static NoneType called None to avoid forcing all
users to spell it NoneType::None.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229980 91177308-0d34-0410-b5e6-96231b3b80d8
If any of the bots complain (perhaps due to an antiquated version of an STL implementation), I will revert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229502 91177308-0d34-0410-b5e6-96231b3b80d8
classes. We can't use template aliases because on MSVC they don't appear
to work correctly in the common usage such as Format.h.
Many thanks to Zach for doing all the testing and debugging here. I just
slotted the fix into the code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229362 91177308-0d34-0410-b5e6-96231b3b80d8
