Skip to content
  1. Jun 30, 2010
    • Duncan Sands's avatar
      Rather than giving SmallPtrSetImpl a member field SmallArray which is magically · 7b90966d
      Duncan Sands authored
      replaced by a bigger array in SmallPtrSet (by overridding it), instead just use a
      pointer to the start of the storage, and have SmallPtrSet pass in the value to use.
      This has the disadvantage that SmallPtrSet becomes bigger by one pointer.  It has
      the advantage that it no longer uses tricky C++ rules, and is clearly correct while
      I'm not sure the previous version was.  This was inspired by g++-4.6 pointing out
      that SmallPtrSetImpl was writing off the end of SmallArray, which it was.  Since
      SmallArray is replaced with a bigger array in SmallPtrSet, the write was still to
      valid memory.  But it was writing off the end of the declared array type - sounds
      kind of dubious to me, like it sounded dubious to g++-4.6.  Maybe g++-4.6 is wrong
      and this construct is perfectly valid and correctly compiled by all compilers, but
      I think it is better to avoid the whole can of worms by avoiding this construct.
      
      llvm-svn: 107285
      7b90966d
  2. Aug 05, 2008
  3. Dec 29, 2007
  4. Nov 06, 2007
  5. Aug 15, 2007
  6. Aug 05, 2007
    • Chris Lattner's avatar
      When clearing a SmallPtrSet, if the set had a huge capacity, but the · 44f7d3aa
      Chris Lattner authored
      contents of the set were small, deallocate and shrink the set.  This
      avoids having us to memset as much data, significantly speeding up
      some pathological cases.  For example, this speeds up the verifier
      from 0.3899s to 0.0763 (5.1x) on the testcase from PR1432 in a 
      release build.
      
      llvm-svn: 40837
      44f7d3aa
  7. Jul 27, 2007
  8. Jul 24, 2007
  9. Jul 19, 2007
  10. Jul 18, 2007
  11. Jul 17, 2007
  12. Jul 16, 2007
  13. Jul 10, 2007
  14. Jul 09, 2007
  15. Jun 22, 2007
  16. Apr 14, 2007
  17. Feb 07, 2007
  18. Feb 06, 2007
  19. Jan 27, 2007
Loading