[PATCH] D154579: [InstCombine] Only perform one iteration

[Nikita Popov via Phabricator via llvm-commits]

nikic created this revision.
nikic added reviewers: goldstein.w.n, aeubanks, fhahn, efriedma, RKSimon.
Herald added subscribers: StephenFan, wenlei.
Herald added a project: All.
nikic requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

InstCombine is a worklist-driven algorithm, which works roughly as follows:

- All instructions are initially pushed to the worklist. The initial order is (roughly) in program order / RPO.
- All newly inserted instructions get added to the worklist.
- When an instruction is folded, its users get added back to the worklist.
- When the use-count of an instruction decreases, it gets added back to the worklist.
- ...plus a bunch of other heuristics on when we should revisit instructions.

On top of the worklist algorithm, InstCombine layers an additional fix-point iteration: If //any// fold was performed in the previous iteration, then InstCombine will re-populate the worklist from scratch and fold the //entire// function again. This continues until a fix-point is reached.

In the vast majority of cases, InstCombine will reach a fix-point within a single iteration: However, a second iteration is performed to verify that this is indeed the fixpoint. We can see this in the statistics for llvm-test-suite:

  "instcombine.NumOneIteration": 411380,
  "instcombine.NumTwoIterations": 117921,
  "instcombine.NumThreeIterations": 236,
  "instcombine.NumFourOrMoreIterations": 2,

The way to read these numbers is that in 411380 cases, InstCombine performs no folds. In 117921 cases it performs a fold and reaches the fix-point within one iteration (the second iteration verifies the fixpoint). In the remaining 238 cases, more than one iteration is needed to reach the fixpoint.

In other words, only in 0.04% of cases are additional iterations needed to reach a fixpoint. Conversely, in 22.3% of cases InstCombine performs a completely useless extra iteration to verify the fix point.

This patch proposes to remove the fixpoint iteration from InstCombine, and to always only perform a single iteration. This results in a major compile-time improvement: http://llvm-compile-time-tracker.com/compare.php?from=b7e38ff22326d7bcbd01f080dc91f47be25e703e&to=40936c7e9324ce41819483f2c02f5bbcefa292a0&stat=instructions%3Au We get a 4-5% compile-time reduction at negligible codegen impact.

This explicitly does accept that we will not reach a fixpoint in all cases. However, this is mitigated by two factors: First, the data suggests that this happens very rarely in practice. Second, InstCombine runs many times during the optimization pipeline (8 times even without LTO), so there are many chances to recover such cases.

This patch primarily serves to get initial feedback: The actual change needs to also add a mechanism to make sure that we don't end up with incomplete InstCombine runs due to worklist management bugs (fixing those is what I've been working on in the last few weeks). My idea here is to add a `verify-fixpoint` option to `instcombine`, which is enabled by default, so that we will verify that the fixpoint is reached in tests simply using `instcombine`. The optimization pipeline on the other hand will construct `instcombine<no-verify-fixpoint>` to not report issues when the full pipeline is used. This should make sure that we don't introduce worklist management bugs by accident. Does this sound like a reasonable approach?

Depends on D75362 <https://reviews.llvm.org/D75362>.


https://reviews.llvm.org/D154579

Files:
  llvm/include/llvm/Transforms/InstCombine/InstCombine.h
  llvm/test/Analysis/ValueTracking/numsignbits-from-assume.ll
  llvm/test/Other/new-pm-print-pipeline.ll
  llvm/test/Other/print-debug-counter.ll
  llvm/test/Transforms/InstCombine/merging-multiple-stores-into-successor.ll
  llvm/test/Transforms/InstCombine/pr55228.ll
  llvm/test/Transforms/InstCombine/shift.ll
  llvm/test/Transforms/PGOProfile/chr.ll
  llvm/test/Transforms/PhaseOrdering/AArch64/matrix-extract-insert.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D154579.537620.patch
Type: text/x-patch
Size: 10348 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230706/058575dd/attachment.bin>