Repository navigation
toml 0.4.9 to 0.5.3 compile for a long time on 2021-10-02 nightly #89524
Description
[dependencies]
config = "=0.9.3"
[profile.release]
panic = "abort"
codegen-units = 1It seems like both the panic setting and codegen-units setting are required.
I don't know what is going on, but LLVM seems to think it's doing something, but it's been doing the same something for the past 30 minutes. perf top says:
41.22% libLLVM-13-rust-1.57.0-nightly.so [.] llvm::getUniqueExitBlocksHelper<llvm::BasicBlock, llvm::LoopBase<llvm::BasicBlock, llvm::Loop>, llvm::LoopBase<llvm::BasicBlock, llvm::Loop>::getUniq
36.17% libLLVM-13-rust-1.57.0-nightly.so [.] llvm::ScalarEvolution::forgetMemoizedResults
7.01% libLLVM-13-rust-1.57.0-nightly.so [.] llvm::Instruction::getSuccessor
5.58% libLLVM-13-rust-1.57.0-nightly.so [.] llvm::ScalarEvolution::getLoopDisposition
2.63% libLLVM-13-rust-1.57.0-nightly.so [.] llvm::ScalarEvolution::getSCEVAtScope
rustc --version --verbose:
rustc 1.57.0-nightly (f03eb6bef 2021-10-02)
binary: rustc
commit-hash: f03eb6bef8ced8a243858b819e013b9caf83d757
commit-date: 2021-10-02
host: x86_64-unknown-linux-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0
Activity
saethlin commentedon Oct 4, 2021
Update: Compilation finished after about 40 minutes.
[-]config = "=0.9.3" compiles forever on 2021-10-02 nightly[/-][+]config = "=0.9.3" compiles for a long time on 2021-10-02 nightly[/+]ehuss commentedon Oct 5, 2021
Bisected to #88243, cc @nikic
apiraino commentedon Oct 6, 2021
@saethlin what's the command you use to reproduce this issue? Do you add some flags, such as
-Znew-llvm-pass-manager?saethlin commentedon Oct 7, 2021
@apiraino No flags. Just
cargo build --releasewith thedependenciesandprofile.releasetables inCargo.toml.Are you having trouble reproducing?
apiraino commentedon Oct 7, 2021
ah yes thank you @saethlin, I didn't read carefully your configuration. yes, I can now reproduce, I believe the issue is in one of the dependencies of
config=0.9.3(dated 2019, so all dependencies are equally old or even older). I've noticed that compilingconfig=0.11doesn't reproduce anymore this issue.Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.
@rustbot label -I-prioritize +P-medium +T-compiler
saethlin commentedon Oct 7, 2021
I'm poking at this. It's out of my expertise, but maybe I'll turn up something useful.
I minimized
configdown to this function:So the regression is reproduced just by something in
toml. It appears first in commitf667495ae34395be9fc3e4bb8801cacf52c2253eand is removed by7c9b0a39db0c4c235db372f88d725fae6e82889fThe older commits compile in release within a few seconds, while the more recent commits need just over a minute. I suggest investigating this based on the older
tomlcommits in that range.[-]config = "=0.9.3" compiles for a long time on 2021-10-02 nightly[/-][+]toml 0.4.9 to 0.5.3 compile for a long time on 2021-10-02 nightly[/+]saethlin commentedon Oct 7, 2021
--debug-pass=Detailstuns up an endless stream of loop passes, which seems cruelly ironicnikic commentedon Oct 9, 2021
Looks like LLVM manages to blow up
_ZN126_$LT$$LT$toml..value..Value$u20$as$u20$serde..de..Deserialize$GT$..deserialize..ValueVisitor$u20$as$u20$serde..de..Visitor$GT$9visit_map17h0937f33df0be8d95Eto approximately 750k instructions.nikic commentedon Oct 9, 2021
Adding some size instrumentation, we end up running the cgscc pipeline on this function four times, which includes inlining and the function simplification pipeline. On each inline, the size jumps from 325 originally to 16069 to 103390 to 778219 instructions. This is not due to devirt iteration. I can avoid the last one by dropping the UpdatedC reprocessing. Something is going catastrophically wrong here in the interaction between the CGSCC pass manager and the inliner.
nikic commentedon Oct 10, 2021
I think the issue here is recursive drop glue that gets recursively inlined. This looks similar to the report at https://bugs.llvm.org/show_bug.cgi?id=45253.
Mark-Simulacrum commentedon Nov 19, 2021
@nikic do we think we can push the patch for fixing this forward on the LLVM side somehow? It seems desirable to fix this as soon as we can, though it likely won't make the next release given the short timeline...
nikic commentedon Nov 19, 2021
@Mark-Simulacrum I don't have much hope for a timely upstream fix. We can cherry-pick https://reviews.llvm.org/D98481. It has minor perf impact per #89830.
adrian17 commentedon Jan 5, 2022
For the record, this and #89647 still appear to hang and consume lots of memory. (I was quietly hoping #92110 would improve it)
Is this still considered a NewPM blocker?
saethlin commentedon Feb 18, 2022
Checking in, the problem documented in this issue no longer reproduces on nightly or stable (1.58.1).
But the example documented in #89647 still seems to be a problem.
nikic commentedon Mar 9, 2022
Closing this one as the specific case doesn't reproduce anymore, and we have other issues tracking similar problems.