[all-commits] [llvm/llvm-project] 2f8e6b: [ScheduleDAGRRList] Limit number of candidates to ...

[Florian Hahn via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 2f8e6b5f3c86a75f6a75c6955e3b4bf0d26c3a91
      https://github.com/llvm/llvm-project/commit/2f8e6b5f3c86a75f6a75c6955e3b4bf0d26c3a91
  Author: Florian Hahn <flo at fhahn.com>
  Date:   2020-07-23 (Thu, 23 Jul 2020)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
    A llvm/test/CodeGen/X86/stress-scheduledagrrlist.ll

  Log Message:
  -----------
  [ScheduleDAGRRList] Limit number of candidates to explore.

Currently popFromQueueImpl iterates over all candidates to find the best
one. While the candidate queue is small, this is not a problem. But it
becomes a problem once the queue gets larger. For example, the snippet
below takes 330s to compile with llc -O0, but completes in 3s with this
patch.

define void @test(i4000000* %ptr) {
entry:
  store i4000000 0, i4000000* %ptr, align 4
  ret void
}

This patch limits the number of candidates to check to 1000. This limit
ensures that it never triggers for test-suite/SPEC2000/SPEC2006 on X86
and AArch64 with -O3, while still drastically limiting the compile-time
in case of very large queues.

It would be even better to use a binary heap to manage to queue
(D83335), but some heuristics change the score of a node in the queue
after another node has been scheduled. I plan to address this for
backends that use the MachineScheduler in the future, but that requires
a more careful evaluation. In the meantime, the limit should help users
impacted by this issue.

The patch includes a slightly smaller version of the motivating example
as test case, to guard against the issue.

Reviewers: efriedma, paquette, niravd

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D84328