Skip to content
  1. Apr 04, 2012
  2. Apr 02, 2012
  3. Mar 31, 2012
  4. Mar 30, 2012
  5. Mar 29, 2012
  6. Mar 28, 2012
  7. Mar 22, 2012
    • Chandler Carruth's avatar
      Revert a series of commits to MCJIT to get the build working in CMake · e26dafeb
      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
      e26dafeb
  8. Mar 21, 2012
  9. Mar 15, 2012
  10. Mar 14, 2012
  11. Mar 13, 2012
  12. Mar 11, 2012
  13. Mar 07, 2012
    • Chandler Carruth's avatar
      Add support to the hashing infrastructure for automatically hashing both · 2bd66afa
      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
      2bd66afa
  14. Mar 06, 2012
  15. Mar 04, 2012
  16. Mar 03, 2012
  17. Mar 02, 2012
    • Chandler Carruth's avatar
      Simplify the pair optimization. Rather than using complex type traits, · 627e8623
      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
      627e8623
    • Chandler Carruth's avatar
      becfda3e
    • Chandler Carruth's avatar
      Fix bad indenting that was left over from cut/paste of the golden values · b101eed3
      Chandler Carruth authored
      for 32-bit builds in here.
      
      llvm-svn: 151885
      b101eed3
    • Chandler Carruth's avatar
      We really want to hash pairs of directly-hashable data as directly · 40119fb9
      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
      40119fb9
    • Chandler Carruth's avatar
      Add support for hashing pairs by delegating to each sub-object. There is · 4718430a
      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
      4718430a
    • Chandler Carruth's avatar
      Remove the misguided extension here that reserved two special values in · 0d7c2788
      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
      0d7c2788
    • Chandler Carruth's avatar
      Re-disable the debug output. The comment is there explaining why we want · 396260c4
      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
      396260c4
    • Chandler Carruth's avatar
      Provide the 32-bit variant of the golden tests. Not sure how I forgot to · 3da57983
      Chandler Carruth authored
      do this initially, sorry.
      
      llvm-svn: 151857
      3da57983
  18. Mar 01, 2012
    • Benjamin Kramer's avatar
      BumpPtrAllocator: Make sure threshold cannot be initialized with a value... · f7e02a0c
      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
      f7e02a0c
    • Argyrios Kyrtzidis's avatar
      If BumpPtrAllocator is requested to allocate a size that exceeds the slab size, · 16558f4d
      Argyrios Kyrtzidis authored
      increase the slab size.
      
      llvm-svn: 151834
      16558f4d
    • Chandler Carruth's avatar
      Rewrite LLVM's generalized support library for hashing to follow the API · 1d03a3b6
      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
      1d03a3b6
  19. Feb 29, 2012
  20. Feb 22, 2012
    • Jakob Stoklund Olesen's avatar
      Fix typos. · 8bde4c07
      Jakob Stoklund Olesen authored
      llvm-svn: 151163
      8bde4c07
    • Chandler Carruth's avatar
      Support was removed from LLVM's MIPS backend for the PSP variant of that · 0c7a7cc7
      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
      0c7a7cc7
    • Jakob Stoklund Olesen's avatar
      Add a Briggs and Torczon sparse set implementation. · 3a0f01f7
      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
      3a0f01f7
  21. Feb 21, 2012
  22. Feb 18, 2012
  23. Feb 07, 2012
  24. Feb 06, 2012
Loading