Open
Description
After bors rolled commit 5ced3da, Fuchsia's canaries began failing their binary size creep checks. See attached screenshot. It's non-obvious why this change would impact codegen on Fuchsia, but I wanted to alert the rust-lang project and commit author that this has occurred.

Metadata
Metadata
Assignees
Labels
Category: An issue highlighting optimization opportunities or PRs implementing suchCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleIssue: Problems and improvements with respect to binary size of generated code.Operating system: FuchsiaRelevant to the compiler team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
tesuji commentedon Jun 27, 2024
The rustc-perf result for #125853 is neutral. Also the code there doesn't change any behaviors in mir tests.
So you might want to bisect again.
Edit: If you want, I could open a try PR to revert suspicious c036594 which I think could be the most responsible in #125853.
@rustbot label +E-needs-mcve
amanda-tait commentedon Jun 27, 2024
Interesting. I've double-checked the bisection and am confident this is the commit after which we observe the size creep. That said, I have no theory of the case for why this is occurring, so I may just be engaging in a post hoc ergo propter hoc fallacy. If the perf result is neutral, that's good evidence that something else may be responsible.
If it's not too much trouble, please open the try PR to see if that sheds more light on what's going on. Note that this is not a blocker for Fuchsia; we just wanted to alert you that we had observed the size creep.
tesuji commentedon Jun 27, 2024
Btw, how did you build rustc on fuchsia ? Did you enable tracing facility ?
rust/config.example.toml
Line 507 in 036b38c
I asked because in the mentioned PR, I changed some tracing level.
lqd commentedon Jun 27, 2024
The tracing level could maybe impact rustc's size but not the produced binaries size 🤔 .
Similarly, a
try
build of the mentioned revert shouldn't provide much more information, unless the fuchsia team tries it to see if it fixes the issue.What could be interesting though is the simplest way to execute the "binary size creep check", and then we could try it within the fuchsia docker image.
lqd commentedon Jun 27, 2024
@amanda-tait @erickt @tmandry @djkoloski @P1n3appl3 #124032 landed a few PRs before #125853 and definitely had binary size increases, did your size checks also flag that one up?
veera-sivarajan commentedon Jun 28, 2024
@rustbot label -needs-triage +O-fuchisa +T-compiler +I-heavy