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
|