Uh oh!
There was an error while loading. Please reload this page.
Update to LLVM 10 - #67759
Conversation
rust-highfive
commented
Dec 31, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
nikic
commented
Dec 31, 2019
First optimization regression, eventually leading to failure to eliminate bounds checks: https://bugs.llvm.org/show_bug.cgi?id=44419 |
nikic
commented
Jan 1, 2020
Second optimization regression: https://bugs.llvm.org/show_bug.cgi?id=44423 |
nikic
commented
Jan 2, 2020
While previously was rotated to we now get which does not get rotated, and thus not simplified subsequently. The reason why we get a switch here (created by SimplifyCFG) is that CVP eliminated a masking operation, namely instruction I'm not yet sure how to address this issue. |
nikic
commented
Jan 2, 2020
Actually, CVP might be both the problem and the solution here ... if we relax https://github.com/llvm/llvm-project/blob/a58da1a2ff039dd3bb4c43db3919995cf4a74cc7/llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp#L315 to allow phis, then condition |
nikic
commented
Jan 3, 2020
@bors try @rust-timer queue |
rust-timer
commented
Jan 3, 2020
Awaiting bors try build completion |
bors
commented
Jan 3, 2020
⌛ Trying commit d6773bf with merge d5ca0b366ee2e90c658ca0334740b4907ac1ce69... |
rust-highfive
commented
Jan 3, 2020
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
commented
Jan 3, 2020
💔 Test failed - checks-azure |
nikic
commented
Jan 3, 2020
@bors try |
bors
commented
Jan 3, 2020
[WIP] Update to LLVM 10 LLVM 10 is going to be branched soon, so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) r? @ghost
bors
commented
Jan 4, 2020
☀️ Try build successful - checks-azure |
rust-timer
commented
Jan 4, 2020
Queued 97588ae with parent c5840f9, future comparison URL. |
rust-timer
commented
Jan 4, 2020
Finished benchmarking try commit 97588ae, comparison URL. |
nikic
commented
Jan 4, 2020
Those are some pretty hefty compile-time regressions. Some local numbers for the largest diffs in LLVM timings on clap-rs (via this script): Haven't tested how stable these numbers are, but we clearly have a big regression in "Global Variable Optimizer" (first time I hear about this pass), some regression in X86 ISel (this tends to get slower with each release, but this seems an unusually large jump) and we now have a lot more MemorySSA runs. Previously there was just one, now there are 5 (!!). Not sure if this is an analysis preservation fail or supposed to be that way. |
nikic
commented
Jan 4, 2020
Looks like the five MemorySSA runs are expected, as MemorySSA is now enabled for loop passes: https://reviews.llvm.org/D58311 The GlobalOpt regression is likely https://reviews.llvm.org/D68298 and hopefully easy to address with a revert. |
nikic
commented
Jan 4, 2020
@bors try @rust-timer queue |
rust-timer
commented
Jan 4, 2020
Awaiting bors try build completion |
bors
commented
Jan 4, 2020
⌛ Trying commit 6011237 with merge 1b6633b46cd7705ec813cfd1cd7083e92f9da903... |
bors
commented
Jan 4, 2020
☀️ Try build successful - checks-azure |
rust-timer
commented
Jan 4, 2020
Queued 1b6633b46cd7705ec813cfd1cd7083e92f9da903 with parent 79cf5e4, future comparison URL. |
rust-timer
commented
Jan 4, 2020
Finished benchmarking try commit 1b6633b46cd7705ec813cfd1cd7083e92f9da903, comparison URL. |
nikic
commented
Jan 4, 2020
Okay, that improved things a bit, reclaiming about 5% in the best case. Still pretty bad compile-time regression overall. |
nikic
commented
Jan 4, 2020
@bors try @rust-timer queue |
rust-timer
commented
Jan 4, 2020
Awaiting bors try build completion |
bors
commented
May 21, 2020
☀️ Test successful - checks-azure |
nnethercote
commented
May 22, 2020
Speaking as someone who has spent a lot of time and effort on rustc's speed, I find these LLVM performance regressions extremely discouraging. Especially given that opt builds are the hardest ones to speed up from the rustc side. @nikic: many thanks for your efforts on tracking and improving LLVM's speed. I sincerely hope that the LLVM project is taking that work seriously and that things will get better in the future. |
nnethercote
commented
May 22, 2020
More generally: an LLVM update is a large change with a lot of potential for regressions, and we are less than two weeks from the end of the dev cycle for 1.45. (No Tools Breakage Week starts on May 27.) Is there any kind of policy or guidance about the timing of landing such large changes? |
cuviper
commented
May 22, 2020
@nnethercote Your efforts are not lost, even if they appear counteracted. Imagine where we would be with this update without your changes on the Rust side! |
EricRahm
commented
May 22, 2020
For what it's worth, we ended up backing out our clang-10 upgrade on the Firefox side due to the severity of the compile time (14%) and runtime performance (11%) regressions. |
nikomatsakis
commented
May 22, 2020
Sorry, I'm not clear on this, but do we have perf results from this change? It seems like we ought to check back and discuss, perhaps at the next compiler team triage meeting. A quick glance at perf.rust-lang.org didn't show anything yet, but it may not have taken into account the effects of this PR. cc @rust-lang/wg-prioritization -- can we add this to our next agenda to check back in? |
Personally, I would be happy to spend 10% longer compiling at |
Final perf results from the landing are here. Lots of red. Interestingly, |
cuviper
commented
May 22, 2020
The net results compared to 45d050c ( |
nnethercote
commented
May 22, 2020
The
Is that comparing the nightly against the most recent beta? It won't look so dire because we've made a bunch of speedups recently, particularly for debug builds. If you filter down to And compare it against this, which is the comparison of that beta against the revision just before the LLVM 10 upgrade. Again, filter down to Or just look at the individual |
cuviper
commented
May 22, 2020
I don't doubt at all that this PR slowed things down. I was trying to see what the overall story from 1.44 to 1.45 will look like, in spite of this. |
nnethercote
commented
Jun 1, 2020
@nikomatsakis: Any update here? The current dev cycle is almost over and the upgrade to LLVM 10 is going to cause a sizeable perf regression without any upside that I'm aware of. |
There's a maintenance upside in bugs that may be fixed in LLVM 10, without Rust having to encounter them and try to backport fixes. For instance, I just got done dealing with an LLVM 9 miscompilation in s390x, rhbz1837660, which was thankfully already fixed in LLVM 10. Of course there's a risk of LLVM regressions too, even apart from performance, but let's hope for forward progress. |
tmandry
commented
Jun 2, 2020
Personally I think our stance in general should be to accept slower opt builds, especially if it results in better code generation (anything else is swimming against the tide for LLVM). For major regressions and regressions to debug builds, we ideally should report to upstream and work with them to identify the cause. For this change specifically, most regressions are for opt builds, but there are some for debug builds. But sticking to a >6mo old version of LLVM is going to cause a lot more pain than it would solve at this point, IMO. Conversely, rolling to new versions of LLVM more frequently makes it far easier to catch and identify regressions like this. |
LLVM 10 is going to be branched soon, so it's a good time to start finding all those tasty new miscompiles and performance regressions ;)
Status:
fhahn proposed https://reviews.llvm.org/D72214.fhahn has reverted the patch.