diff options
author | Florian Hahn <flo@fhahn.com> | 2020-07-23 10:14:32 +0100 |
---|---|---|
committer | Florian Hahn <flo@fhahn.com> | 2020-07-23 11:35:33 +0100 |
commit | 2f8e6b5f3c86a75f6a75c6955e3b4bf0d26c3a91 (patch) | |
tree | 9a9f9f0473c8561504828bf4d7f45c584d92be18 /llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp | |
parent | 20c3386f4a0bc39aa33512dcad024c678e89f9c4 (diff) | |
download | llvm-2f8e6b5f3c86a75f6a75c6955e3b4bf0d26c3a91.zip llvm-2f8e6b5f3c86a75f6a75c6955e3b4bf0d26c3a91.tar.gz llvm-2f8e6b5f3c86a75f6a75c6955e3b4bf0d26c3a91.tar.bz2 |
[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
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp')
0 files changed, 0 insertions, 0 deletions