compiletime can blow up when building with optimizations and debug info #48226
Comments
|
Building the slow config (optimizations + debuginfo) with beta only takes 16.5 seconds btw so this is a beta to (EDIT: |
|
Hi! Can you reproduce the issue using rustc stable ? |
|
Stable looks fine as well |
gsollazzo
added
A-LLVM
|
Thanks, as there is no existing label to tag beta-to-nightly regressions, I've assigned "regression-from-stable-to-nightly". @Manishearth Shall we add a "regression_from_beta_to_nightly" tag? |
|
Maybe it would make more sense to have 1.23-to-1.24 / 1.24-to-1.25 etc tags otherwise things might get confusing when nightly become beta and beta becomes stable? (not sure how this is handled currently) |
|
Currently it's not really handled, but I do have some plans as to how to best handle it. Expect to hear more soon. |
|
@gsollazzo I don't understand why we would need a regression_from_beta_to_nightly, at least in this case ... if the problem arised in nightly but is not witnessed in stable (nor in beta either), then it is indeed a regression from stable to nightly, no? (in other words, I think the tag you added is fine?) |
|
triage: P-high We need to narrow this down. Can somebody try bisecting through nightly releases or PRs? That would be very helpful. It is possible that the difference is due to the fact that -- for some time -- we were using ThinLTO as the default. i.e., maybe the problem is that lto=true is now doing a full lto? I can't remember the exact chronology there. |
|
Out of those, #47828 (LLVM 5 -> LLVM 6) seems by far the most likely suspect. |
|
Sounds quite likely. |
|
@pnkfelix You're right, but in this case the regression was from beta 1.24 to nightly 1.25, therefore the usual release cycle is inverted. (btw, sorry for the closing-and-reopening of the issue, I pressed the wrong button...) |
|
I've bisected this to https://bugs.llvm.org/show_bug.cgi?id=36417 |
|
I am not sure if it is related, but it sounds so. I am working in embedded Rust and I am currently on Nightly. I tracked it down to: Is this particular issue the cause of the problems? P.S. Please be aware I am using also Xargo and GCC to link the binary, but as neither of those changed recently I think the problem might be related to this conversation. |
|
@Lakier15 I don't see any reason to suspect this is the same bug, even though from the dates it seems likely that the same PR (LLVM upgrade) introduced the problem. Please file a separate issue with steps to reproduce. |
|
@rkruppe I will try to produce a minimum reproducible example and file it in a separate issue. |
|
Update from @rust-lang/compiler meeting: decided to leave this as P-high until we get some more information from the LLVM side. |
|
triage: the LLVM ticket that @alexcrichton linked (https://bugs.llvm.org/show_bug.cgi?id=36417) has some ideas on ways to address this. But we still need someone to try those ideas out (or come up with new ones)
|
|
A patch has been proposed: https://reviews.llvm.org/D43956 |
|
Update: the patch has landed: llvm-mirror/llvm@783006e 🎉 |
This pulls in the rest of LLVM's `release_60` branch (the actual 6.0.0 release) and also pulls in a cherry-pick to... Closes rust-lang#48226
|
I've confirmed the LLVM patch fixes the issue here and have opened #48782 and beta-nominated it |
|
🎉 |
This pulls in the rest of LLVM's `release_60` branch (the actual 6.0.0 release) and also pulls in a cherry-pick to... Closes rust-lang#48226
src/main.rs
Cargo toml:
so far so good.
Now lets add
debug=trueto Cargo.toml release flagsOoops....
Looks like most of the time is spent in llvm:
This might be a sideeffect of the llvm6 upgrade.
The text was updated successfully, but these errors were encountered: