| 36b56886974eae4f9c5ebc96befd3e7bfe5de338 |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Update to LLVM 3.5a.
Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/include/llvm/Support/type_traits.h
|
| 7fe65d691dcce550d53ec9310913aab67ab6d654 |
|
27-Mar-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Cleanup the simplify_type implementation.
As far as simplify_type is concerned, there are 3 kinds of smart pointers:
* const correct: A 'const MyPtr<int> &' produces a 'const int*'. A
'MyPtr<int> &' produces a 'int *'.
* always const: Even a 'MyPtr<int> &' produces a 'const int*'.
* no const: Even a 'const MyPtr<int> &' produces a 'int*'.
This patch then does the following:
* Removes the unused specializations. Since they are unused, it is hard
to know which kind should be implemented.
* Make sure we don't drop const.
* Fix the default forwarding so that const correct pointer only need
one specialization.
* Simplifies the existing specializations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178147 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 01812bebcc345b09ce261317b6fdefde8f097642 |
|
20-Jan-2013 |
Michael J. Spencer <bigcheesegs@gmail.com> |
[Support] Port ErrorOr<T> from lld to C++03.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172991 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 0067567927b3dad6457158ebc51fedc7ed163cb6 |
|
13-Sep-2012 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Fix some code which is invalid in C++11: an expression of enumeration type
can't be used as a non-type template argument of type bool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163840 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 18883037a98240a7831c0d7c01dbe502fc5cfbd9 |
|
28-Apr-2012 |
Benjamin Kramer <benny.kra@googlemail.com> |
If the __is_trivially_copyable type trait is available use it as the baseline for isPodLike.
This way we can enable the POD-like class optimization for a lot more classes,
saving ~120k of code in clang/i386/Release+Asserts when selfhosting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155761 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 4e58263459d7f9ae862b52adafe585b66411272f |
|
06-Apr-2012 |
Benjamin Kramer <benny.kra@googlemail.com> |
DenseMap: Perform the pod-like object optimization when the value type is POD-like, not the DenseMapInfo for it.
Purge now unused template arguments. This has been broken since r91421. Patch by Lubos Lunak!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154170 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| cbfc117674be7ff70b4682c525d6fcb4827a74ed |
|
07-Mar-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Try a completely different approach to this type trait to appease older
compilers. It seems that GCC 4.3 (and likely older) simply aren't going
to do SFINAE on non-type template parameters the way Clang and modern
GCCs do...
Now we detect the implicit conversion to an integer type, and then
blacklist classes, pointers, and floating point types. This seems to
work well enough, and I'm hopeful will return the bots to life.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152227 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| ff12877a6f4db734cf0a156dc2ef815a839a79ec |
|
07-Mar-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Attempt #2 at appeasing GCC 4.3. This compiler really doesn't like these
traits.
With this change, the pattern used here is *extremely* close to the
pattern used elsewhere in the file, so I'm hoping it survives the
build-bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152225 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| a1eb50fe3d8213156c77ef2f7ae5c4ad629dbb95 |
|
07-Mar-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Switch the is_integral_or_enum trait machinery to use an explicit
template argument and an *implicit* conversion from '0' to a null
pointer. For some bizarre reason, GCC 4.3.2 thinks that the cast to
'(T*)' is invalid inside of an enumerator's value... which it isn't but
whatever. ;] This pattern is used elsewhere in the type_traits header
and so hopefully will survive the wrath of the build bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152220 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| d4d8b2a7f6d29b44cbc084b49042f44ef109da0c |
|
07-Mar-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Add support to the hashing infrastructure for automatically hashing both
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
/external/llvm/include/llvm/Support/type_traits.h
|
| 1c1448984d43f1f02c0235d35ebe8460c9b57afd |
|
02-Mar-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Simplify the pair optimization. Rather than using complex type traits,
just ensure that the number of bytes in the pair is the sum of the bytes
in each side of the pair. As long as thats true, there are no extra
bytes that might be padding.
Also add a few tests that previously would have slipped through the
checking. The more accurate checking mechanism catches these and ensures
they are handled conservatively correctly.
Thanks to Duncan for prodding me to do this right and more simply.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151891 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 88c48fae6956f17273704da53a2b3ab2981529c1 |
|
02-Mar-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Add a header that was technically missing to see if this gets the
offsetof buildbot errors to go away...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151884 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 4d628e200f7133e353c38806b57a229ef6ad2ab4 |
|
02-Mar-2012 |
Chandler Carruth <chandlerc@gmail.com> |
We really want to hash pairs of directly-hashable data as directly
hashable data. This matters when we have pair<T*, U*> as a key, which is
quite common in DenseMap, etc. To that end, we need to detect when this
is safe. The requirements on a generic std::pair<T, U> are:
1) Both T and U must satisfy the existing is_hashable_data trait. Note
that this includes the requirement that T and U have no internal
padding bits or other bits not contributing directly to equality.
2) The alignment constraints of std::pair<T, U> do not require padding
between consecutive objects.
3) The alignment constraints of U and the size of T do not conspire to
require padding between the first and second elements.
Grow two somewhat magical traits to detect this by forming a pod
structure and inspecting offset artifacts on it. Hopefully this won't
cause any compilers to panic.
Added and adjusted tests now that pairs, even nested pairs, are treated
as just sequences of data.
Thanks to Jeffrey Yasskin for helping me sort through this and reviewing
the somewhat subtle traits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151883 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 0b66c6fca22e85f732cf58f459a06c06833d1882 |
|
01-Mar-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Rewrite LLVM's generalized support library for hashing to follow the API
of the proposed standard hashing interfaces (N3333), and to use
a modified and tuned version of the CityHash algorithm.
Some of the highlights of this change:
-- Significantly higher quality hashing algorithm with very well
distributed results, and extremely few collisions. Should be close to
a checksum for up to 64-bit keys. Very little clustering or clumping of
hash codes, to better distribute load on probed hash tables.
-- Built-in support for reserved values.
-- Simplified API that composes cleanly with other C++ idioms and APIs.
-- Better scaling performance as keys grow. This is the fastest
algorithm I've found and measured for moderately sized keys (such as
show up in some of the uniquing and folding use cases)
-- Support for enabling per-execution seeds to prevent table ordering
or other artifacts of hashing algorithms to impact the output of
LLVM. The seeding would make each run different and highlight these
problems during bootstrap.
This implementation was tested extensively using the SMHasher test
suite, and pased with flying colors, doing better than the original
CityHash algorithm even.
I've included a unittest, although it is somewhat minimal at the moment.
I've also added (or refactored into the proper location) type traits
necessary to implement this, and converted users of GeneralHash over.
My only immediate concerns with this implementation is the performance
of hashing small keys. I've already started working to improve this, and
will continue to do so. Currently, the only algorithms faster produce
lower quality results, but it is likely there is a better compromise
than the current one.
Many thanks to Jeffrey Yasskin who did most of the work on the N3333
paper, pair-programmed some of this code, and reviewed much of it. Many
thanks also go to Geoff Pike Pike and Jyrki Alakuijala, the original
authors of CityHash on which this is heavily based, and Austin Appleby
who created MurmurHash and the SMHasher test suite.
Also thanks to Nadav, Tobias, Howard, Jay, Nick, Ahmed, and Duncan for
all of the review comments! If there are further comments or concerns,
please let me know and I'll jump on 'em.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151822 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| dc2e570411bb1b1345a6b9840050aca823835a81 |
|
15-Dec-2009 |
Chris Lattner <sabre@nondot.org> |
improve isPodLike to know that all non-class types are pod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91425 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 4bbf4ee1491637c247e195e19e3e4a8ee5ad72fa |
|
15-Dec-2009 |
Chris Lattner <sabre@nondot.org> |
Remove isPod() from DenseMapInfo, splitting it out to its own
isPodLike type trait. This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91421 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 81cf4325698b48b02eddab921ac333c7f25005c3 |
|
10-Nov-2009 |
Jeffrey Yasskin <jyasskin@google.com> |
Fix DenseMap iterator constness.
This patch forbids implicit conversion of DenseMap::const_iterator to
DenseMap::iterator which was possible because DenseMapIterator inherited
(publicly) from DenseMapConstIterator. Conversion the other way around is now
allowed as one may expect.
The template DenseMapConstIterator is removed and the template parameter
IsConst which specifies whether the iterator is constant is added to
DenseMapIterator.
Actually IsConst parameter is not necessary since the constness can be
determined from KeyT but this is not relevant to the fix and can be addressed
later.
Patch by Victor Zverovich!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86636 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 71a5c22c2b635ea903c3ae7d2695ca649b38726f |
|
23-Oct-2009 |
Jeffrey Yasskin <jyasskin@google.com> |
Try r84890 again (adding ValueMap<>), now that I've tested the compile on
gcc-4.4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84902 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| a84c9db467ce55e68464e6a099dcfe934b513a2a |
|
22-Oct-2009 |
Jeffrey Yasskin <jyasskin@google.com> |
Revert r84890, which broke the linux build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84892 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| e0a234029b1b65f21169536f4c45e83743ed3cfa |
|
22-Oct-2009 |
Jeffrey Yasskin <jyasskin@google.com> |
Add a ValueMap<ValueOrSubclass*, T> type. ValueMap<Value*, T> is safe to use
even when keys get RAUWed and deleted during its lifetime. By default the keys
act like WeakVHs, but users can pass a third template parameter to configure
how updates work and whether to do anything beyond updating the map on each
action.
It's also possible to automatically acquire a lock around ValueMap updates
triggered by RAUWs and deletes, to support the ExecutionEngine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84890 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 404aa26b26eb62c57daac8246159220eb173ae94 |
|
13-Oct-2009 |
Douglas Gregor <dgregor@apple.com> |
Add is_same type trait
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84029 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| a9ad04191cb56c42944b17980b8b2bb2afe11ab2 |
|
13-Aug-2009 |
Dan Gohman <gohman@apple.com> |
This void is implicit in C++.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78848 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| c7a6da6e1469100937851cc3741a36b5850e54da |
|
04-Aug-2009 |
Douglas Gregor <dgregor@apple.com> |
Add some type traits that are used for Clang's statically-checked
canonical types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78076 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 7ed47a13356daed2a34cd2209a31f92552e3bdd8 |
|
29-Dec-2007 |
Chris Lattner <sabre@nondot.org> |
Don't attribute in file headers anymore. See llvmdev for the
discussion of this change. Boy are my fingers tired. ;-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45411 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 63b3afa98460ce38a1c48d3c44ef6edfdaf37b77 |
|
21-Apr-2005 |
Misha Brukman <brukman+llvm@gmail.com> |
Remove trailing whitespace
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@21411 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 551ccae044b0ff658fe629dd67edd5ffe75d10e8 |
|
02-Sep-2004 |
Reid Spencer <rspencer@reidspencer.com> |
Changes For Bug 352
Move include/Config and include/Support into include/llvm/Config,
include/llvm/ADT and include/llvm/Support. From here on out, all LLVM
public header files must be under include/llvm/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16137 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|
| 5c4d53a4d1bce60051fd71af1791791acb2000da |
|
24-Feb-2004 |
Chris Lattner <sabre@nondot.org> |
Check in a new type_traits header which provides the mysterious is_class
template. Thanks go out to Reid Spencer for skillfully extracting this
from boost!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11784 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/include/llvm/Support/type_traits.h
|