aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/LiveDebugVariables.cpp
diff options
context:
space:
mode:
authorWei Mi <wmi@google.com>2018-07-16 15:42:20 +0000
committerWei Mi <wmi@google.com>2018-07-16 15:42:20 +0000
commit40c4aa7637d07a807ceb8f2a5d7d69cf3d50085a (patch)
tree6934ceedbfcc6392134e9f677200122f6706f5f2 /llvm/lib/CodeGen/LiveDebugVariables.cpp
parentb1d17f64e554e4eea6307284336e9ea87343d433 (diff)
downloadllvm-40c4aa7637d07a807ceb8f2a5d7d69cf3d50085a.zip
llvm-40c4aa7637d07a807ceb8f2a5d7d69cf3d50085a.tar.gz
llvm-40c4aa7637d07a807ceb8f2a5d7d69cf3d50085a.tar.bz2
[RegAlloc] Skip global splitting if the live range is huge and its spill is
trivially rematerializable. We run into a case where machineLICM hoists a large number of live ranges outside of a big loop because it thinks those live ranges are trivially rematerializable. In regalloc, global splitting is tried out first for those live ranges before they are spilled and rematerialized. Because the global splitting algorithm is quadratic, increasing a lot of global splitting candidates causes huge compile time increase (50s to 1400s on my local machine when compiling a module). However, we think for live ranges which are very large and are trivially rematerialiable, it is better to just skip global splitting so as to save compile time with little chance of sacrificing performance. We uses the segment size of live range to indirectly evaluate whether the global splitting of the live range can introduce high cost, and use an option as a knob to adjust the size limit threshold. Differential Revision: https://reviews.llvm.org/D49353 llvm-svn: 337186
Diffstat (limited to 'llvm/lib/CodeGen/LiveDebugVariables.cpp')
0 files changed, 0 insertions, 0 deletions