[PATCH] D89080: [SCCP] Reduce the number of times ResolvedUndefsIn is called for large modules.

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 8 16:39:06 PDT 2020


efriedma created this revision.
efriedma added a reviewer: fhahn.
Herald added a subscriber: hiraditya.
Herald added a project: LLVM.
efriedma requested review of this revision.

If a module has many values that need to be resolved by ResolvedUndefsIn, compilation takes quadratic time overall.  Solve should do a small amount of work, since not much is added to the worklists each time markOverdefined is called. But ResolvedUndefsIn is linear over the length of the function/module, so resolving one undef at a time is quadratic in general.

To solve this, make ResolvedUndefsIn resolve every undef value at once, instead of resolving them one at a time.  This loses a little optimization power, but can be a lot faster.

We still need a loop around ResolvedUndefsIn because markOverdefined could change the set of blocks that are live.  That should be uncommon, hopefully. We could optimize it by tracking which blocks transition from dead to live, instead of iterating over the whole module to find them.  But I'll leave that for later.  (The whole function will become a lot simpler once we start pruning branches on undef.)

The regression test changes seem minor.  The specific cases in question could probably be optimized with a bit more work, but they seem like edge cases that don't really matter.

Fixes an "infinite" compile issue my team found on an internal workoad.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89080

Files:
  llvm/lib/Transforms/Scalar/SCCP.cpp
  llvm/test/Transforms/SCCP/2004-12-10-UndefBranchBug.ll
  llvm/test/Transforms/SCCP/resolvedundefsin-tracked-fn.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D89080.297076.patch
Type: text/x-patch
Size: 5239 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201008/0fe3936d/attachment.bin>


More information about the llvm-commits mailing list