[PATCH][Review Requested][Compilation Time]

[Owen Anderson]

IIRC, it's backed by a hashtable once it overflows the small size, so it's O(1) beyond that.  That said, this could still be an improvement in memory efficiency.

--Owen

On Jan 31, 2013, at 8:45 PM, Craig Topper <craig.topper at gmail.com> wrote:

> SmallPtrSet only does a linear scan when the space is small. Once the set grows beyond the small size then it should be O(log n). So I would wonder if the SmallPtrSets that have a size of 16 actually see a real performance increase from this change. I also wonder if shrinking the existing SmallPtrSets to less than 64 might show gains since they would fall over to logarithmic behavior sooner.
> 
> On Thu, Jan 31, 2013 at 8:15 PM, Craig Topper <craig.topper at gmail.com> wrote:
> I haven't looked in detail, but there are many 80 column violations in this patch.
> 
> On Thu, Jan 31, 2013 at 6:28 PM, Nowicki, Tyler <tyler.nowicki at intel.com> wrote:
> Hi,
> 
>  
> 
> This patch aims to improve compile time performance by replacing uses of SmallPtrSet in SelectionDAG with a new class called FlagVector. The SmallPtrSet is used for keeping track of SDNode pointers. For example, in DAGCombiner.cpp it is used to keep a track of each unique SDNode in the working list. Performing an insert into a SmallPtrSet causes it to loop over all entries to determine if the pointer has been stored before. This patch avoids this O(N) operation by given each SDNode a unique number that is then used to index into the FlagVector. Since a SelectionDAG is instantiated for each function, its FlagVector doesn’t grow prohibitively large.
> 
>  
> 
> Although FlagVector may appear similar to SmallVector it differs slightly in the semantics of its array operator which will grow the vector to contain the SDNode index. Suggestions are welcome on potential reuses of SmallVector, however, it is very convenient to have an array operator which automatically grows the vector. We have another patch coming which uses the FlagVector in the same manner.
> 
>  
> 
> This patch is part of a series of compile time improvements. Although these were originally produced by our colleague Wan Xiaofei, our team consisting of preston.gurd at intel.com; sriram.murali at intel.com and myself, are assuming all responsibility for this work.
> 
>  
> 
> PLEASE REVIEW. Thanks!
> 
>  
> 
> Tyler Nowicki
> 
> Intel
> 
>  
> 
> Benchmark
> 
> Trunk
> 
> Numbering.SD
> 
> 401.bzip2
> 
> 74.21
> 
> 72.34
> 
> 403.gcc
> 
> 73.88
> 
> 72.01
> 
> 429.mcf
> 
> 72.80
> 
> 71.22
> 
> 433.milc
> 
> 78.78
> 
> 76.75
> 
> 444.namd
> 
> 94.73
> 
> 93.37
> 
> 445.gobmk
> 
> 36.28
> 
> 35.38
> 
> 450.soplex
> 
> 71.41
> 
> 69.66
> 
> 456.hmmer
> 
> 86.80
> 
> 84.78
> 
> 458.sjeng
> 
> 96.38
> 
> 94.44
> 
> 464.h264ref
> 
> 87.61
> 
> 85.93
> 
> 470.lbm
> 
> 68.95
> 
> 67.97
> 
> 471.omnetpp
> 
> 89.07
> 
> 86.91
> 
> bitmnp01
> 
> 84.06
> 
> 82.61
> 
> cjpegv2data6
> 
> 59.70
> 
> 58.42
> 
> idctrn01
> 
> 40.18
> 
> 39.08
> 
> libquake2
> 
> 48.48
> 
> 47.10
> 
> libquake_portable
> 
> 63.54
> 
> 62.03
> 
> libxcsoar
> 
> 47.44
> 
> 45.92
> 
> linpack
> 
> 142.14
> 
> 140.99
> 
> matrix01
> 
> 24.75
> 
> 24.11
> 
> nbench
> 
> 108.04
> 
> 106.59
> 
> tblook01
> 
> 44.03
> 
> 43.30
> 
> ttsprk01
> 
> 39.23
> 
> 38.23
> 
> Geomean
> 
> 65.85
> 
> 64.41
> 
>  
> 
> 401.bzip2
> 
> 100.00
> 
> 102.59
> 
> 403.gcc
> 
> 100.00
> 
> 102.60
> 
> 429.mcf
> 
> 100.00
> 
> 102.22
> 
> 433.milc
> 
> 100.00
> 
> 102.64
> 
> 444.namd
> 
> 100.00
> 
> 101.46
> 
> 445.gobmk
> 
> 100.00
> 
> 102.54
> 
> 450.soplex
> 
> 100.00
> 
> 102.51
> 
> 456.hmmer
> 
> 100.00
> 
> 102.38
> 
> 458.sjeng
> 
> 100.00
> 
> 102.05
> 
> 464.h264ref
> 
> 100.00
> 
> 101.96
> 
> 470.lbm
> 
> 100.00
> 
> 101.44
> 
> 471.omnetpp
> 
> 100.00
> 
> 102.49
> 
> bitmnp01
> 
> 100.00
> 
> 101.76
> 
> cjpegv2data6
> 
> 100.00
> 
> 102.19
> 
> idctrn01
> 
> 100.00
> 
> 102.81
> 
> libquake2
> 
> 100.00
> 
> 102.93
> 
> libquake_portable
> 
> 100.00
> 
> 102.43
> 
> libxcsoar
> 
> 100.00
> 
> 103.31
> 
> linpack
> 
> 100.00
> 
> 100.82
> 
> matrix01
> 
> 100.00
> 
> 102.65
> 
> nbench
> 
> 100.00
> 
> 101.36
> 
> tblook01
> 
> 100.00
> 
> 101.69
> 
> ttsprk01
> 
> 100.00
> 
> 102.62
> 
> Geomean
> 
> 100.00
> 
> 102.24
> 
>  
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 
> 
> 
> -- 
> ~Craig
> 
> 
> 
> -- 
> ~Craig _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130131/d2b0f67f/attachment.html>