LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 38047 - Regression in compile time during Jump Threading passes between LLVM 6 and 7
Summary: Regression in compile time during Jump Threading passes between LLVM 6 and 7
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Scalar Optimizations (show other bugs)
Version: trunk
Hardware: PC Windows NT
: P enhancement
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-03 20:09 PDT by Alex Crichton
Modified: 2018-07-10 00:27 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Crichton 2018-07-03 20:09:55 PDT
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
Comment 1 Alex Crichton 2018-07-03 20:10:59 PDT
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
Comment 2 Alex Crichton 2018-07-03 22:47:11 PDT
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?
Comment 3 Florian Hahn 2018-07-04 02:35:09 PDT
Adding recent PR37929, which contains a source file where a huge amount of time is spent in jump threading.
Comment 4 Davide Italiano 2018-07-05 08:05:59 PDT
Michael, can you revert this while investigating the problem? I think this shouldn't go to LLVM 7.
Comment 5 Michael Zolotukhin 2018-07-05 15:11:03 PDT
Agreed, reverted in r336393.
Comment 6 Alex Crichton 2018-07-05 15:30:27 PDT
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