Skip to content
  1. Dec 04, 2012
  2. Nov 30, 2012
    • Chandler Carruth's avatar
      Switch LLVM_USE_RVALUE_REFERENCES to LLVM_HAS_RVALUE_REFERENCES. · f12e3a67
      Chandler Carruth authored
      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.
      
      llvm-svn: 168996
      f12e3a67
  3. Nov 08, 2012
  4. Oct 29, 2012
    • Ulrich Weigand's avatar
      Implement arithmetic on APFloat with PPCDoubleDouble semantics by · d9f7e259
      Ulrich Weigand authored
      treating it as if it were an IEEE floating-point type with 106-bit
      mantissa.
      
      This makes compile-time arithmetic on "long double" for PowerPC
      in clang (in particular parsing of floating point constants)
      work, and fixes all "long double" related failures in the test
      suite.
      
      llvm-svn: 166951
      d9f7e259
  5. Oct 23, 2012
  6. Oct 16, 2012
  7. Oct 14, 2012
  8. Oct 12, 2012
  9. Oct 03, 2012
  10. Sep 26, 2012
  11. Sep 15, 2012
  12. Aug 30, 2012
  13. Aug 15, 2012
  14. Aug 01, 2012
    • Chandler Carruth's avatar
      Add range erase, element insert, and range insert methods to · f2113f3b
      Chandler Carruth authored
      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. ;]
      
      llvm-svn: 161104
      f2113f3b
  15. Jul 31, 2012
    • Chandler Carruth's avatar
      Implement copy and move assignment for TinyPtrVector. These try to · 94ed2107
      Chandler Carruth authored
      re-use allocated vectors as much as possible.
      
      llvm-svn: 161041
      94ed2107
    • Chandler Carruth's avatar
      Bring TinyPtrVector under test. Somehow we never picked up unit tests · a565375a
      Chandler Carruth authored
      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.
      
      llvm-svn: 161024
      a565375a
    • Chandler Carruth's avatar
      Move the SmallVector unit tests to be type-parameterized so that we can · 0b01261c
      Chandler Carruth authored
      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.
      
      llvm-svn: 161001
      0b01261c
  16. Jun 21, 2012
    • Chandler Carruth's avatar
      Completely refactor the structuring of unittest CMake files to match the · 94d02518
      Chandler Carruth authored
      Makefiles, the CMake files in every other part of the LLVM tree, and
      sanity.
      
      This should also restore the output tree structure of all the unit
      tests, sorry for breaking that, and thanks for letting me know.
      
      The fundamental change is to put a CMakeLists.txt file in the unittest
      directory, with a single test binary produced from it. This has several
      advantages:
      
      - No more weird directory stripping in the unittest macro, allowing it
        to be used more readily in other projects.
      - No more directory prefixes on all the source files.
      - Allows correct and precise use of LLVM's per-directory dependency
        system.
      - Allows use of the checking logic for source files that have not been
        added to the CMake build. This uncovered a file being skipped with
        CMake in LLVM and one in Clang's unit tests.
      - Makes Specifying conditional compilation or other custom logic for JIT
        tests easier.
      
      It did require adding the concept of an explicit 'optional' source file
      to the CMake build so that the missing-file check can skip cases where
      the file is *supposed* to be missing. =]
      
      This is another chunk of refactoring the CMake build in order to make it
      usable for other clients like CompilerRT / ASan / TSan.
      
      Note that this is interdependent with a Clang CMake change.
      
      llvm-svn: 158909
      94d02518
  17. Jun 19, 2012
    • Chandler Carruth's avatar
      Fix PR13148, an inf-loop in StringMap. · 198422a4
      Chandler Carruth authored
      StringMap suffered from the same bug as DenseMap: when you explicitly
      construct it with a small number of buckets, you can arrange for the
      tombstone-based growth path to be followed when the number of buckets
      was less than '8'. In that case, even with a full map, it would compare
      '0' as not less than '0', and refuse to grow the table, leading to
      inf-loops trying to find an empty bucket on the next insertion. The fix
      is very simple: use '<=' as the comparison. The same fix was applied to
      DenseMap as well during its recent refactoring.
      
      Thanks to Alex Bolz for the great report and test case. =]
      
      llvm-svn: 158725
      198422a4
    • Chandler Carruth's avatar
      Remove some superfluous SCOPED_TRACEs from this unit test. · fc3856d9
      Chandler Carruth authored
      GoogleTest already prints errors with all the information about which
      test case contained the error.
      
      llvm-svn: 158724
      fc3856d9
  18. Jun 17, 2012
    • Benjamin Kramer's avatar
      Remove SmallMap unittests, unbreaking the build. · ae7f7937
      Benjamin Kramer authored
      I don't know how useful these are for SmallDenseMap, I'll leave that decision to Chandler.
      
      llvm-svn: 158646
      ae7f7937
    • Benjamin Kramer's avatar
      Bring the return value of SmallVector::insert in line with std::vector::insert. · 23a9c3e0
      Benjamin Kramer authored
      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.
      
      llvm-svn: 158645
      23a9c3e0
    • Benjamin Kramer's avatar
      SmallVector: return a valid iterator for the rare case of inserting an empty... · 371b9b0e
      Benjamin Kramer authored
      SmallVector: return a valid iterator for the rare case of inserting an empty range into a SmallVector.
      
      Patch by Johannes Schaub!
      
      llvm-svn: 158643
      371b9b0e
    • Chandler Carruth's avatar
      Add a unit test for 'swap', and fix a pile of bugs in · 4de807a5
      Chandler Carruth authored
      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.
      
      llvm-svn: 158641
      4de807a5
    • Chandler Carruth's avatar
      Add tests for *DenesMap for both key and value types' construction and · a1be842f
      Chandler Carruth authored
      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.
      
      llvm-svn: 158639
      a1be842f
    • Chandler Carruth's avatar
      Introduce a SmallDenseMap container that re-uses the existing DenseMap · 20dd838a
      Chandler Carruth authored
      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. =]
      
      llvm-svn: 158638
      20dd838a
  19. Jun 16, 2012
  20. Jun 02, 2012
  21. May 24, 2012
  22. May 22, 2012
  23. May 15, 2012
  24. May 14, 2012
Loading