Use the existing move implementation of the internal DenseMap::InsertIntoBucket
method to provide a user-facing move insert method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172453 91177308-0d34-0410-b5e6-96231b3b80d8
With DenseMapInfo<Enum>, it is miscompiled on g++-4.4.
static inline Enum getEmptyKey() { return Enum(<arbitrary int/unsigned value>); }
isEauql(getEmptyKey(), ...)
The compiler mis-assumes the return value is not aliased to Enum.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171600 91177308-0d34-0410-b5e6-96231b3b80d8
The iplist::clear() function can be quite expensive because it traverses
the entire list, calling deleteNode() and removeNodeFromList() on each
element. If node destruction and deallocation can be handled some other
way, clearAndLeakNodesUnsafely() can be used to jettison all nodes
without bringing them into cache.
The function name is meant to be ominous.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171540 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes Valgrind failures and removes bitwise operations that don't provide any benefit.
Valgrind failures reported by NAKAMURA Takumi.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171413 91177308-0d34-0410-b5e6-96231b3b80d8
re-use that for SlotIndexes. This way other users who want half-open
semantics can share the implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171158 91177308-0d34-0410-b5e6-96231b3b80d8
The single-element ilist::splice() function supports a noop move:
List.splice(I, List, I);
The corresponding std::list function doesn't allow that, so add a unit
test to document that behavior.
This also means that
List.splice(I, List, F);
is somewhat surprisingly not equivalent to
List.splice(I, List, F, next(F));
This patch adds an assertion to catch the illegal case I == F above.
Alternatively, we could make I == F a legal noop, but that would make
ilist differ even more from std::list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170443 91177308-0d34-0410-b5e6-96231b3b80d8
This is an alternative to the ImmutableMapRef interface where a factory
should still be canonicalizing by default, but in certain cases an
improvement can be made by delaying the canonicalization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169532 91177308-0d34-0410-b5e6-96231b3b80d8
textually as NativeClient. Also added a link to the native client project for
readers unfamiliar with it.
A Clang patch will follow shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169291 91177308-0d34-0410-b5e6-96231b3b80d8
AKA: Recompile *ALL* the source code!
This one went much better. No manual edits here. I spot-checked for
silliness and grep-checked for really broken edits and everything seemed
good. It all still compiles. Yell if you see something that looks goofy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169133 91177308-0d34-0410-b5e6-96231b3b80d8
Rationale:
1) This was the name in the comment block. ;]
2) It matches Clang's __has_feature naming convention.
3) It matches other compiler-feature-test conventions.
Sorry for the noise. =]
I've also switch the comment block to use a \brief tag and not duplicate
the name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168996 91177308-0d34-0410-b5e6-96231b3b80d8
references from whether it supports an R-value reference *this. No
version of GCC today supports the latter, which breaks GCC C++11
compiles of LLVM and Clang now.
Also add doxygen comments clarifying what's going on here, and update
the usage in Optional. I'll update the usages in Clang next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168993 91177308-0d34-0410-b5e6-96231b3b80d8
This expands to '&', and is intended to be used when an /optional/ rvalue
override is available.
Before:
void foo() const { ... }
After:
void foo() const LLVM_LVALUE_FUNCTION { ... }
void foo() && { ... }
This is used to allow moving the contents of an Optional.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168963 91177308-0d34-0410-b5e6-96231b3b80d8
Similarly to several recent fixes throughout the code replace std::map use with the MapVector.
Add find() method to the MapVector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168051 91177308-0d34-0410-b5e6-96231b3b80d8
APInt::shl generated llvm.trap to guard against shifts greater than bit-width.
This was already checked with an assert, and there was a special case for
shifts equal to bit-width. Modify this check to catch shifts greater than or
equal to bit-width, so llvm.trap isn't generated.
Patch contributed by JF Bastien
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166803 91177308-0d34-0410-b5e6-96231b3b80d8
While LLVM itself is still C++03, there's no reason why tools built on
top of it can't use C++11 features.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166242 91177308-0d34-0410-b5e6-96231b3b80d8
This allows llvm::Optional to be used with movable-but-not-copyable types.
While LLVM itself is still C++03, there's no reason why tools built on
top of it can't use C++11 features.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166241 91177308-0d34-0410-b5e6-96231b3b80d8
most of the behavior we want, but wrap the predicate in one which erases
elements from the set if they pass the predicate. Oh what I wouldn't
give for a lambda here.
Let me know if the predicate wrapping is too much magic. ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165076 91177308-0d34-0410-b5e6-96231b3b80d8
preserves the values of the relocated entries, unlikely remove_if. This
allows walking them and erasing them.
Also flesh out the predicate we are using for this to support the
various constraints actually imposed on a UnaryPredicate -- without this
we can't compose it with std::not1.
Thanks to Sean Silva for the review here and noticing the issue with
std::remove_if.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165073 91177308-0d34-0410-b5e6-96231b3b80d8
scheduled for processing on the worklist eventually gets deleted while
we are processing another alloca, fixing the original test case in
PR13990.
To facilitate this, add a remove_if helper to the SetVector abstraction.
It's not easy to use the standard abstractions for this because of the
specifics of SetVectors types and implementation.
Finally, a nice small test case is included. Thanks to Benjamin for the
fantastic reduced test case here! All I had to do was delete some empty
basic blocks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165065 91177308-0d34-0410-b5e6-96231b3b80d8
This adds 'elf' as a recognized target triple environment value and overrides the default generated object format on Windows platforms if that value is present. This patch also enables MCJIT tests on Windows using the new environment value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165030 91177308-0d34-0410-b5e6-96231b3b80d8
This silences literally dozens of analyzer warnings on LLVM (since DenseMap
is such a commonly-used class).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164438 91177308-0d34-0410-b5e6-96231b3b80d8
provide insertion order iteration, instead of the old option of
DenseMap order iteration over keys and insertion order iteration over
values.
This is implemented by keeping two copies of each key.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164221 91177308-0d34-0410-b5e6-96231b3b80d8
* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
people want -- it starts a new paragraph);
* use \param instead of \arg to document parameters in order to be consistent
with the rest of the codebase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163902 91177308-0d34-0410-b5e6-96231b3b80d8
* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
people want -- it starts a new paragraph).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163790 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the code guarded with ANDROIDEABI are not
ARM-specific, and having no relation with arm-eabi.
Thus, it will be more natural to call this
environment "Android" instead of "ANDROIDEABI".
Note: We are not using ANDROID because several projects
are using "-DANDROID" as the conditional compilation
flag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163087 91177308-0d34-0410-b5e6-96231b3b80d8
Changes the hash result for strings containing characters
with values >= 128, such as UTF8 strings (not normal ASCII).
Changed mostly so we match other implementations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162882 91177308-0d34-0410-b5e6-96231b3b80d8
Adds the vendor 'fsl' (used by Freescale SDK) to Triple. This will allow
clang support for Freescale cross-compile configurations.
Patch by Tobias von Koch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162726 91177308-0d34-0410-b5e6-96231b3b80d8
TinyPtrVector. With these, it is sufficiently functional for my more
normal / pedestrian uses.
I've not included some r-value reference stuff here because the value
type for a TinyPtrVector is, necessarily, just a pointer.
I've added tests that cover the basic behavior of these routines, but
they aren't as comprehensive as I'd like. In particular, they don't
really test the iterator semantics as thoroughly as they should. Maybe
some brave soul will feel enterprising and flesh them out. ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161104 91177308-0d34-0410-b5e6-96231b3b80d8
for this class. These tests exercise most of the basic properties, but
the API for TinyPtrVector is very strange currently. My plan is to start
fleshing out the API to match that of SmallVector, but I wanted a test
for what is there first.
Sadly, it doesn't look reasonable to just re-use the SmallVector tests,
as this container can only ever store pointers, and much of the
SmallVector testing is to get construction and destruction right.
Just to get this basic test working, I had to add value_type to the
interface.
While here I found a subtle bug in the combination of 'erase', 'begin',
and 'end'. Both 'begin' and 'end' wanted to use a null pointer to
indicate the "end" iterator of an empty vector, regardless of whether
there is actually a vector allocated or the pointer union is null.
Everything else was fine with this except for erase. If you erase the
last element of a vector after it has held more than one element, we
return the end iterator of the underlying SmallVector which need not be
a null pointer. Instead, simply use the pointer, and poniter + size()
begin/end definitions in the tiny case, and delegate to the inner vector
whenever it is present.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161024 91177308-0d34-0410-b5e6-96231b3b80d8
test more than a single instantiation of SmallVector.
Add testing for 0, 1, 2, and 4 element sized "small" buffers. These
appear to be essentially untested in the unit tests until now.
Fix several tests to be robust in the face of a '0' small buffer. As
a consequence of this size buffer, the growth patterns are actually
observable in the test -- yes this means that many tests never caused
a grow to occur before. For some tests I've merely added a reserve call
to normalize behavior. For others, the growth is actually interesting,
and so I captured the fact that growth would occur and adjusted the
assertions to not assume how rapidly growth occured.
Also update the specialization for a '0' small buffer length to have all
the same interface points as the normal small vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161001 91177308-0d34-0410-b5e6-96231b3b80d8
The rationale here is that it's hard to write loops containing vector erases and
it only shows up if the vector contains non-trivial objects leading to crashes
when forming them out of garbage memory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160854 91177308-0d34-0410-b5e6-96231b3b80d8
the comparison. This prevents large unsigned integers from being equal to
signed negative integers of the same bit width.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160642 91177308-0d34-0410-b5e6-96231b3b80d8
For a measure of safety, this conversion is only permitted if the
stored pointer type can also be created from a const void *.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160456 91177308-0d34-0410-b5e6-96231b3b80d8
These functions have obviously never been used before.
They should be identical to the idf_ext_iterator counterparts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160381 91177308-0d34-0410-b5e6-96231b3b80d8
Make it possible to prune individual graph edges from a post-order
traversal by specializing the po_iterator_storage template. Previously,
it was only possible to prune full graph nodes. Edge pruning makes it
possible to remove loop back-edges, for example.
Also replace the existing DFSetTraits customization hook with a
po_iterator_storage method for observing the post-order. DFSetTraits was
only used by LoopIterator.h which now provides a po_iterator_storage
specialization.
Thanks to Sean and Chandler for reviewing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160366 91177308-0d34-0410-b5e6-96231b3b80d8
some, and allows the routine to be inlined into common callers. The
various bits that hit this code in their hotpath seem slightly lower on
the profile, but I can't really measure a performance improvement as
everything seems to still be bottlenecked on likely cache misses. =/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159648 91177308-0d34-0410-b5e6-96231b3b80d8
There is a pretty staggering amount of this in LLVM's header files, this
is not all of the instances I'm afraid. These include all of the
functions that (in my build) are used by a non-static inline (or
external) function. Specifically, these issues were caught by the new
'-Winternal-linkage-in-inline' warning.
I'll try to just clean up the remainder of the clearly redundant "static
inline" cases on functions (not methods!) defined within headers if
I can do so in a reliable way.
There were even several cases of a missing 'inline' altogether, or my
personal favorite "static bool inline". Go figure. ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158800 91177308-0d34-0410-b5e6-96231b3b80d8
Based on review discussion of r158638 with Chandler Carruth, Tobias von Koch, and Duncan Sands and a -Wmaybe-uninitialized warning from GCC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158685 91177308-0d34-0410-b5e6-96231b3b80d8
It always returns the iterator for the first inserted element, or the passed in
iterator if the inserted range was empty. Flesh out the unit test more and fix
all the cases it uncovered so far.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158645 91177308-0d34-0410-b5e6-96231b3b80d8
We have SmallDenseMap now that has more correct and predictable
semantics, even though it is a more narrow abstraction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158644 91177308-0d34-0410-b5e6-96231b3b80d8
SmallDenseMap::swap.
First, make it parse cleanly. Yay for uninstantiated methods.
Second, make the inline-buckets case work correctly. This is way
trickier than it should be due to the uninitialized values in empty and
tombstone buckets.
Finally fix a few typos that caused construction/destruction mismatches
in the counting unittest.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158641 91177308-0d34-0410-b5e6-96231b3b80d8
destruction and fix a bug in SmallDenseMap they caught.
This is kind of a poor-man's version of the testing that just adds the
addresses to a set on construction and removes them on destruction. We
check that double construction and double destruction don't occur.
Amusingly enough, this is enough to catch a lot of SmallDenseMap issues
because we spend a lot of time with fixed stable addresses in the inline
buffer.
The SmallDenseMap bug fix included makes grow() not double-destroy in
some cases. It also fixes a FIXME there, the code was pretty crappy. We
now don't have any wasted initialization, but we do move the entries in
inline bucket array an extra time. It's probably a better tradeoff, and
is much easier to get correct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158639 91177308-0d34-0410-b5e6-96231b3b80d8
implementation.
This type includes an inline bucket array which is used initially. Once
it is exceeded, an array of 64 buckets is allocated on the heap. The
bucket count grows from there as needed. Some highlights of this
implementation:
- The inline buffer is very carefully aligned, and so supports types
with alignment constraints.
- It works hard to avoid aliasing issues.
- Supports types with non-trivial constructors, destructors, copy
constructions, etc. It works reasonably hard to minimize copies and
unnecessary initialization. The most common initialization is to set
keys to the empty key, and so that should be fast if at all possible.
This class has a performance / space trade-off. It tries to optimize for
relatively small maps, and so packs the inline bucket array densely into
the object. It will be marginally slower than a normal DenseMap in a few
use patterns, so it isn't appropriate everywhere.
The unit tests for DenseMap have been generalized a bit to support
running over different map implementations in addition to different
key/value types. They've then been automatically extended to cover the
new container through the magic of GoogleTest's typed tests.
All of this is still a bit rough though. I'm going to be cleaning up
some aspects of the implementation, documenting things better, and
adding tests which include non-trivial types. As soon as I'm comfortable
with the correctness, I plan to switch existing users of SmallMap over
to this class as it is already more correct w.r.t. construction and
destruction of objects iin the map.
Thanks to Benjamin Kramer for all the reviews of this and the lead-up
patches. That said, more review on this would really be appreciated. As
I've noted a few times, I'm quite surprised how hard it is to get the
semantics for a hashtable-based map container with a small buffer
optimization correct. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158638 91177308-0d34-0410-b5e6-96231b3b80d8
rather than the base class. Add a pile of boilerplate to indirect around
this.
This is pretty ugly, but it allows the super class to change the
representation of these values, which will be key for doing
a SmallDenseMap.
Suggestions on better method structuring / naming are welcome, but keep
in mind that SmallDenseMap won't have an 'unsigned' member to expose
a reference to... =/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158586 91177308-0d34-0410-b5e6-96231b3b80d8
and a derived class that provides the allocation and growth strategy.
This is the first (and biggest) step toward building a SmallDenseMap
that actually behaves exactly the same as DenseMap, and supports all the
same types and interface points with the same semantics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158585 91177308-0d34-0410-b5e6-96231b3b80d8
The only missing part is insert(), which uses a pair of parameters and I haven't
figured out how to convert it to rvalue references. It's now possible to use a
DenseMap with std::unique_ptr values :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157539 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise just looking up a value in the map requires creating a VH, adding it to the use lists and destroying it again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157124 91177308-0d34-0410-b5e6-96231b3b80d8
Returning a temporary BitVector is very expensive. If you must, create
the temporary explicitly: Use BitVector(A).flip() instead of ~A.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156768 91177308-0d34-0410-b5e6-96231b3b80d8
These operators were crazy slow, calling malloc to return a temporary
result. At the same time, they look very innocent when used in code.
If you need temporary BitVectors to compute your thing, create them
explicitly, and use the inplace logical operators. This makes the high
cost explicit in the code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156767 91177308-0d34-0410-b5e6-96231b3b80d8
This new function provides a way to get the iOS version number from ios triples.
Part of rdar://11409204
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156483 91177308-0d34-0410-b5e6-96231b3b80d8
The new target machines are:
nvptx (old ptx32) => 32-bit PTX
nvptx64 (old ptx64) => 64-bit PTX
The sources are based on the internal NVIDIA NVPTX back-end, and
contain more functionality than the current PTX back-end currently
provides.
NV_CONTRIB
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156196 91177308-0d34-0410-b5e6-96231b3b80d8
but using a FoldingSet underneath and with a largely compatible
interface to that of FoldingSet. This can be used anywhere a FoldingSet
would be natural, but iteration order is significant. The initial
intended use case is in Clang's template specialization lists to
preserve instantiation order iteration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156131 91177308-0d34-0410-b5e6-96231b3b80d8
Note that support for rvalue references does not imply support
for the full set of move-related STL operations.
I've preserved support for an odd little thing in insert() where
we're trying to support inserting a new element from an existing
one. If we actually want to support that, there's a lot more we
need to do: insert can call either grow or push_back, neither of
which is safe against this particular use pattern.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155979 91177308-0d34-0410-b5e6-96231b3b80d8
- FlatArrayMap. Very simple map container that uses flat array inside.
- MultiImplMap. Map container interface, that has two modes, one for small amount of elements and one for big amount.
- SmallMap. SmallMap is DenseMap compatible MultiImplMap. It uses FlatArrayMap for small mode, and DenseMap for big mode.
Also added unittests for new classes and update for ProgrammersManual.
For more details about new classes see ProgrammersManual and comments in sourcecode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155557 91177308-0d34-0410-b5e6-96231b3b80d8
This nicely handles the most common case of virtual register sets, but
also handles anticipated cases where we will map pointers to IDs.
The goal is not to develop a completely generic SparseSet
template. Instead we want to handle the expected uses within llvm
without any template antics in the client code. I'm adding a bit of
template nastiness here, and some assumption about expected usage in
order to make the client code very clean.
The expected common uses cases I'm designing for:
- integer keys that need to be reindexed, and may map to additional
data
- densely numbered objects where we want pointer keys because no
number->object map exists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155227 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
optimizers could do this for us, but expecting partial SROA of classes
with template methods through cloning is probably expecting too much
heroics. With this change, the begin/end pointer pairs which indicate
the status of each loop iteration are actually passed directly into each
layer of the combine_data calls, and the inliner has a chance to see
when most of the combine_data function could be deleted by inlining.
Similarly for 'length'.
We have to be careful to limit the places where in/out reference
parameters are used as those will also defeat the inliner / optimizers
from properly propagating constants.
With this change, LLVM is able to fully inline and unroll the hash
computation of small sets of values, such as two or three pointers.
These now decompose into essentially straight-line code with no loops or
function calls.
There is still one code quality problem to be solved with the hashing --
LLVM is failing to nuke the alloca. It removes all loads from the
alloca, leaving only lifetime intrinsics and dead(!!) stores to the
alloca. =/ Very unfortunate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154264 91177308-0d34-0410-b5e6-96231b3b80d8
ImmutAVLTree uses random unsigned values as keys into a DenseMap,
which could possibly happen to be the same value as the Tombstone or
Entry keys in the DenseMap.
Test case is hard to come up with. We randomly get failures on the
internal static analyzer bot, which most likely hits this issue
(hard to be 100% sure without the full stack).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153148 91177308-0d34-0410-b5e6-96231b3b80d8
Commit r152704 exposed a latent MSVC limitation (aka bug).
Both ilist and and iplist contains the same function:
template<class InIt> void insert(iterator where, InIt first, InIt last) {
for (; first != last; ++first) insert(where, *first);
}
Also ilist inherits from iplist and ilist contains a "using iplist<NodeTy>::insert".
MSVC doesn't know which one to pick and complain with an error.
I think it is safe to delete ilist::insert since it is redundant anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152746 91177308-0d34-0410-b5e6-96231b3b80d8
caused several clients to select the slow variation. =[ This is extra
annoying because we don't have any realistic way of testing this -- by
design, these two functions *must* compute the same value.
Found while inspecting the output of some benchmarks I'm working on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152369 91177308-0d34-0410-b5e6-96231b3b80d8
buildbots. Original commit message:
[ADT] Change the trivial FoldingSetNodeID::Add* methods to be inline, reapplied
with a fix for the longstanding over-read of 32-bit pointer values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152304 91177308-0d34-0410-b5e6-96231b3b80d8
Deleting them because they aren't used. =D
Yell if you need these, I'm happy to instead replace them with nice uses
of the new infrastructure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152219 91177308-0d34-0410-b5e6-96231b3b80d8
integral and enumeration types. This is accomplished with a bit of
template type trait magic. Thanks to Richard Smith for the core idea
here to detect viable types by detecting the set of types which can be
default constructed in a template parameter.
This is used (in conjunction with a system for detecting nullptr_t
should it exist) to provide an is_integral_or_enum type trait that
doesn't need a whitelist or direct compiler support.
With this, the hashing is extended to the more general facility. This
will be used in a subsequent commit to hashing more things, but I wanted
to make sure the type trait magic went through the build bots separately
in case other compilers don't like this formulation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152217 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
complains about the truncation of a 64-bit constant to a 32-bit value
when size_t is 32-bits wide, but *only with static_cast*!!! The exact
signal that should *silence* such a warning, and in fact does silence it
with both GCC and Clang.
Anyways, this was causing grief for all the MSVC builds, so pointless
change made. Thanks to Nikola on IRC for confirming that this works.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152021 91177308-0d34-0410-b5e6-96231b3b80d8
new hash_value infrastructure, and replace their implementations using
hash_combine. This removes a complete copy of Jenkin's lookup3 hash
function (which is both significantly slower and lower quality than the
one implemented in hash_combine) along with a somewhat scary xor-only
hash function.
Now that APInt and APFloat can be passed directly to hash_combine,
simplify the rest of the LLVMContextImpl hashing to use the new
infrastructure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152004 91177308-0d34-0410-b5e6-96231b3b80d8
