-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Closed
Copy link
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.I-compiletimeIssue: Problems and improvements with respect to compile times.Issue: Problems and improvements with respect to compile times.P-highHigh priorityHigh priorityllvm-fixed-upstreamIssue expected to be fixed by the next major LLVM upgrade, or backported fixesIssue expected to be fixed by the next major LLVM upgrade, or backported fixesregression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Description
Building comrak
with cargo build --release
seems to never finish on x86_64 (both on Windows and Linux). It normally builds on the stable channel on my machine in approximately 26 seconds.
Bisect results:
searched nightlies: from nightly-2025-02-15 to nightly-2025-02-25
regressed nightly: nightly-2025-02-18
searched commit range: 5bc6231...ce36a96
regressed commit: ce36a96
bisected with cargo-bisect-rustc v0.6.9
Host triple: x86_64-pc-windows-msvc
Reproduce with:
cargo bisect-rustc --start=2025-02-15 --end=2025-02-25 --script "C:\\Program Files\\Git\\usr\\bin\\bash.exe" -- ./regress.sh
regress.sh
:
#!/bin/bash
set -eux -o pipefail
timeout 60 cargo build --release
@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged
kornelski and Dan0xE
Metadata
Metadata
Assignees
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.I-compiletimeIssue: Problems and improvements with respect to compile times.Issue: Problems and improvements with respect to compile times.P-highHigh priorityHigh priorityllvm-fixed-upstreamIssue expected to be fixed by the next major LLVM upgrade, or backported fixesIssue expected to be fixed by the next major LLVM upgrade, or backported fixesregression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
saethlin commentedon Mar 3, 2025
perf top
during a compile of the above looks like this:This is not a hang, the build completes after 20 minutes (phew).
moxian commentedon Mar 3, 2025
This can be somewhat "minimized" to just
scanners::autolink_email
function, which has no external dependencies and can be tested in isolation (when decorated with#[no_mangle]
or similar)It's a huge match statement, and I would guess codegen takes polynomial time somehow?
Limiting the match the first 70 cases (0-69) makes the function compile in 85 seconds on my machine (~instant on stable);
Limiting it to the first 60 cases (0-59) drops the time down to 40 seconds
Limiting to first 50 (0-49) drops it further to 16sec
Having all 128 match arms, but deleting either arm 2 (
2=>{return None;}
) or arm 11 (11=>{return Some(cursor);}
) makes it compile near-instantly. Which is probably not surprising since those are the only two return paths.Minimized further:
llvm passes timings:
apiraino commentedon Mar 3, 2025
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-high
8 remaining items