[PATCH] D74986: [LiveDebugValues] Encode register location within VarLoc IDs [3/3]

[Vedant Kumar via Phabricator via llvm-commits]

vsk created this revision.
vsk added reviewers: aprantl, jmorse.
vsk added a project: debug-info.
Herald added a subscriber: hiraditya.
Herald added a project: LLVM.

This is part 3 of a 3-part series to address a compile-time explosion
issue in LiveDebugValues.

---

Start encoding register locations within VarLoc IDs, and take advantage
of this encoding to speed up transferRegisterDef.

There is no fundamental algorithmic change: this patch simply swaps out
SparseBitVector in favor of CoalescingBitVector. That changes iteration
order (hence the test updates), but otherwise this patch is NFCI.

The only interesting change is in transferRegisterDef. Instead of doing:

  KillSet = {}
  DeadRegs = // Find the regs killed by MI.
  for (each ID in the OpenLocs set)
    if (ID is in DeadRegs)
      add ID to the KillSet

We now do:

  KillSet = {}
  DeadRegs = // Find the regs killed by MI.
  for (each Reg in the DeadRegs set)
    for (each ID in the interval range for Reg)
      add ID to the KillSet

By not visiting each open location every time we visit an instruction,
this eliminates some potentially quadratic behavior. The new
implementation basically does a constant amount of work per instruction
because the interval map lookups are very fast.

For a file in WebKit, this brings the time spent in LiveDebugValues down
from ~2.5 minutes to 4 seconds, reducing compile time spent in that pass
from 28% of the total to just over 1%.

Before:

  2.49 min   27.8%	0 s	LiveDebugValues::process
  2.41 min   27.0%	5.40 s	LiveDebugValues::transferRegisterDef
  1.51 min   16.9%	1.51 min LiveDebugValues::VarLoc::isDescribedByReg() const
  32.73 s    6.1%		8.70 s	 llvm::SparseBitVector<128u>::SparseBitVectorIterator::operator++()

After:

  4.53 s	1.1%	0 s	LiveDebugValues::process
  3.00 s	0.7%	107.00 ms		LiveDebugValues::transferRegisterCopy
  892.00 ms	0.2%	406.00 ms	LiveDebugValues::transferSpillOrRestoreInst
  404.00 ms	0.1%	32.00 ms	LiveDebugValues::transferRegisterDef
  110.00 ms	0.0%	2.00 ms		  LiveDebugValues::getUsedRegs
  57.00 ms	0.0%	1.00 ms		  std::__1::vector<>::push_back
  40.00 ms	0.0%	1.00 ms		  llvm::CoalescingBitVector<>::find(unsigned long long)

FWIW, I tried the same approach using SparseBitVector, but got bad
results. To do that, I had to extend SparseBitVector to support 64-bit
indices and expose its lower bound operation. The problem with this is
that the performance is very hard to predict: SparseBitVector's lower
bound operation falls back to O(n) linear scans in a std::list if you're
not /very/ careful about managing iteration order. When I profiled this
the performance looked worse than the baseline.

You can see the full CoalescingBitVector-based implementation here:

  https://github.com/vedantk/llvm-project/commits/try-coalescing

You can see the full SparseBitVector-based implementation here:

  https://github.com/vedantk/llvm-project/commits/try-sparsebitvec-find

Depends on: https://reviews.llvm.org/D74985


https://reviews.llvm.org/D74986

Files:
  llvm/lib/CodeGen/LiveDebugValues.cpp
  llvm/test/DebugInfo/MIR/X86/entry-values-diamond-bbs.mir
  llvm/test/DebugInfo/MIR/X86/multiple-param-dbg-value-entry.mir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D74986.245958.patch
Type: text/x-patch
Size: 17213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200221/0599a6c9/attachment.bin>