[PATCH][Review Requested][Compilation Time]

[Owen Anderson]

Could this FlagVector not be a SparseBitVector or a BitVector?

--Owen

On 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 ofpreston.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
>  
> <Numbering-svn.patch>_______________________________________________
> 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/52da28d1/attachment.html>