We're currently attempting [1] to upgrade to the tip of LLVM in Rust and it looks like all our tests are green but it looks like we've got a compile-time performance regression that may prevent us from upgrading. We've tested LLVM 7 against what we're currently running against, LLVM 6, and it looks like across the board we're seeing a bit of a performance regression [2]. Taking a look at the biggest regression on that list it looks like LLVM's Jump Threading pass may be the culprit here. I've extracted some IR from the Rust compiler and verified that this command: $ opt -O2 lib.ll -o /dev/null takes ~18s locally on LLVM 6 and ~40s on LLVM's master branch right now (or at least pretty close to it as of this writing). Passing `-time-passes` shows that on LLVM 6 the Jump Threading pass takes 13.7s and on LLVM 7 it takes 34.9s where other passes remain roughly the same. Next up I'll try to bisect this to see if I can hunt down a particular commit, but in the meantime someone else may have an idea as well! [1]: https://github.com/rust-lang/rust/pull/51966 [2]: https://perf.rust-lang.org/compare.html?start=81d5c3e78374df15c40f463cef27918a80f3b234&end=921ebab62aa9541715ebde1db0ecf3b0d0891e92&stat=instructions%3Au
Er so it looks like the IR is a bit too large to attach to this bug. The test is a bit of a silly stress test in rustc right now, so the IR is a bit large! I've uploaded it here though: https://gist.github.com/alexcrichton/c4712bffbc8dfd6124e1de6f73f2226a
I've bisected this issue to https://reviews.llvm.org/D44282 where the attached IR jumps (locally) from ~14 to ~40s in `opt -O2`, mostly spent in the jump threading pass. I've cc'd the author and approver of that commit, would y'all mind help taking a look into this?
Adding recent PR37929, which contains a source file where a huge amount of time is spent in jump threading.
Michael, can you revert this while investigating the problem? I think this shouldn't go to LLVM 7.
Agreed, reverted in r336393.
Thanks for the quick fix/patch! I can confirm on my end at least that the reverted commit restores the original runtime of the test case on this bug