[PATCH] Speed up creation of live ranges for physical registers by using a segment set

Vaidas Gasiunas vaidas.gasiunas at sap.com
Tue Oct 28 07:12:19 PDT 2014


Hi qcolombet, atrick, Gerolf,

The patch addresses a compile-time performance regression in the LiveIntervals analysis pass (see http://llvm.org/bugs/show_bug.cgi?id=18580). This regression is especially critical when compiling long functions. Our analysis had shown that the most of time is taken for generation of live intervals for physical registers. Insertions in the middle of the array of live ranges cause quadratic algorithmic complexity, which is apparently the main reason for the slow-down. 

Overview of changes:
- The patch introduces an additional std::set<Segment>* member in LiveRange for storing segments in the phase of initial creation. The set is used if this member is not NULL, otherwise everything works the old way. 
- The set of operations on LiveRange used during initial creation (i.e. used by createDeadDefs and extendToUses) have been reimplemented to use the segment set if it is available.
- After a live range is created the contents of the set are flushed to the segment vector, because the set is not as efficient as the vector for the later uses of the live range. After the flushing, the set is deleted and cannot be used again.
- The set is only for live ranges computed in LiveIntervalAnalysis::computeLiveInRegUnits() and getRegUnit() but not in computeVirtRegs(), because I did not bring any performance benefits to computeVirtRegs() and for some examples even brought a slow down.

http://reviews.llvm.org/D6013

Files:
  include/llvm/CodeGen/LiveInterval.h
  include/llvm/CodeGen/LiveIntervalAnalysis.h
  lib/CodeGen/LiveInterval.cpp
  lib/CodeGen/LiveIntervalAnalysis.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D6013.15522.patch
Type: text/x-patch
Size: 14166 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141028/9a451f64/attachment.bin>


More information about the llvm-commits mailing list