- Apr 16, 2012
-
-
Duncan Sands authored
through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy' value, which may be a number in ULPs or the keyword 'fast', however the intent is that this will be extended with additional information about NaN's, infinities etc later. No optimizations have been hooked up to this so far. llvm-svn: 154822
-
- Apr 15, 2012
-
-
Duncan Sands authored
llvm-svn: 154766
-
- Apr 04, 2012
-
-
Michael J. Spencer authored
llvm-svn: 153977
-
- Apr 02, 2012
-
-
Hal Finkel authored
llvm-svn: 153882
-
- Mar 31, 2012
-
-
Duncan Sands authored
node and returning it if one didn't exist. llvm-svn: 153798
-
- Mar 30, 2012
-
-
Rafael Espindola authored
needed for correctness, but still doesn't clean up code that now unnecessary checks for reachability. llvm-svn: 153755
-
- Mar 29, 2012
-
-
Danil Malyshev authored
llvm-svn: 153672
-
- Mar 28, 2012
-
-
Danil Malyshev authored
llvm-svn: 153607
-
- Mar 22, 2012
-
-
Chandler Carruth authored
(and hopefully on Windows). The bots have been down most of the day because of this, and it's not clear to me what all will be required to fix it. The commits started with r153205, then r153207, r153208, and r153221. The first commit seems to be the real culprit, but I couldn't revert a smaller number of patches. When resubmitting, r153207 and r153208 should be folded into r153205, they were simple build fixes. llvm-svn: 153241
-
- Mar 21, 2012
-
-
Danil Malyshev authored
Based on this discussion: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120305/138477.html 1. Declare a virtual function getPointerToNamedFunction() in JITMemoryManager 2. Move the implementation of getPointerToNamedFunction() form JIT/MCJIT to DefaultJITMemoryManager. llvm-svn: 153205
-
- Mar 15, 2012
-
-
Eli Bendersky authored
llvm-svn: 152780
-
- Mar 14, 2012
-
-
Eli Bendersky authored
llvm-svn: 152703
-
- Mar 13, 2012
-
-
Eli Bendersky authored
Also refactor the existing OProfile profiling code to reuse the same interfaces with the VTune profiling code. In addition, unit tests for the profiling interfaces were added. This patch was prepared by Andrew Kaylor and Daniel Malea, and reviewed in the llvm-commits list by Jim Grosbach llvm-svn: 152620
-
- Mar 11, 2012
-
-
Michael J. Spencer authored
llvm-svn: 152522
-
Michael J. Spencer authored
it would fail with {,u}int64_t on x86-64 Linux. This also removes code duplication. llvm-svn: 152517
-
- Mar 07, 2012
-
-
Chandler Carruth authored
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. llvm-svn: 152217
-
- Mar 06, 2012
-
-
Benjamin Kramer authored
SmallPtrSet: Provide a more efficient implementation of swap than the default triple-copy std::swap. This currently assumes that both sets have the same SmallSize to keep the implementation simple, a limitation that can be lifted if someone cares. llvm-svn: 152143
-
- Mar 04, 2012
-
-
Chandler Carruth authored
llvm-svn: 152003
-
Chandler Carruth authored
llvm-svn: 152000
-
Chandler Carruth authored
llvm-svn: 151999
-
- Mar 03, 2012
-
-
Francois Pichet authored
Move the NonPOD struct out of the anonymous namespace instead of adding llvm:: everywhere to fix the HashingTest on MSVC . chandlerc proposed this better solution on IRC. llvm-svn: 151974
-
Francois Pichet authored
llvm-svn: 151971
-
NAKAMURA Takumi authored
unittests/ADT/HashingTest.cpp: Temporarily disable a new test introduced in r151891, to appease msvc. llvm-svn: 151970
-
- Mar 02, 2012
-
-
Chandler Carruth authored
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. llvm-svn: 151891
-
Chandler Carruth authored
llvm-svn: 151886
-
Chandler Carruth authored
for 32-bit builds in here. llvm-svn: 151885
-
Chandler Carruth authored
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. llvm-svn: 151883
-
Chandler Carruth authored
an open question of whether we can do better than this by treating pairs as boring data containers and directly hashing the two subobjects. This at least makes the API reasonable. In order to make this change, I reorganized the header a bit. I lifted the declarations of the hash_value functions up to the top of the header with their doxygen comments as these are intended for users to interact with. They shouldn't have to wade through implementation details. I then defined them at the very end so that they could be defined in terms of hash_combine or any other hashing infrastructure. Added various pair-hashing unittests. llvm-svn: 151882
-
Chandler Carruth authored
the hash_code. I'm not sure what I was thinking here, the use cases for special values are in the *keys*, not in the hashes of those keys. We can always resurrect this if needed, or clients can accomplish the same goal themselves. This makes the general case somewhat faster (~5 cycles faster on my machine) and smaller with less branching. llvm-svn: 151865
-
Chandler Carruth authored
to keep this around -- updating golden tests is annoying otherwise. Thanks to Benjamin for pointing this omission out on IRC. llvm-svn: 151860
-
Chandler Carruth authored
do this initially, sorry. llvm-svn: 151857
-
- Mar 01, 2012
-
-
Benjamin Kramer authored
BumpPtrAllocator: Make sure threshold cannot be initialized with a value smaller than the slab size. This replaces r151834 with a simpler fix. llvm-svn: 151842
-
Argyrios Kyrtzidis authored
increase the slab size. llvm-svn: 151834
-
Chandler Carruth authored
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. llvm-svn: 151822
-
- Feb 29, 2012
-
-
Daniel Dunbar authored
llvm-svn: 151747
-
- Feb 22, 2012
-
-
Jakob Stoklund Olesen authored
llvm-svn: 151163
-
Chandler Carruth authored
chip in r139383, and the PSP components of the triple are really annoying to parse. Let's leave this chapter behind. There is no reason to expect LLVM to see a PSP-related triple these days, and so no reasonable motivation to support them. It might be reasonable to prune a few of the older MIPS triple forms in general, but as those at least cause no burden on parsing (they aren't both a chip and an OS!), I'm happy to leave them in for now. llvm-svn: 151156
-
Jakob Stoklund Olesen authored
For objects that can be identified by small unsigned keys, SparseSet provides constant time clear() and fast deterministic iteration. Insert, erase, and find operations are typically faster than hash tables. SparseSet is useful for keeping information about physical registers, virtual registers, or numbered basic blocks. llvm-svn: 151110
-
- Feb 21, 2012
-
-
Chandler Carruth authored
construction. Simplify its interface, implementation, and users accordingly as there is no longer an 'uninitialized' state to check for. Also, fixes a bug lurking in the interface as there was one method that didn't correctly check for initialization. llvm-svn: 151024
-
- Feb 18, 2012
-
-
Talin authored
llvm-svn: 150890
-