-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Binary size regression on msp430 when using Cell
with types from external crates.
#67819
Comments
While diagnosing another issue, I came back to this one. The script I used to bisect was buggy; the actual commit where dead code stopped being optimized away was 955979a. As of recent (well as of me writing this) commit dbe459d, I can get the dead code elimination to work again using the following patch:
This isn't a public interface, so I think the patch can be used as-is. However, I imagine there was a reason that I wonder if it's possible for Rust to optimize the trait objects out anyway if LTO is enabled? cc: @cuviper if you have the chance? |
Hmm, that commit was an ad-hoc request in #62596 (comment) (cc @sfackler). Ironically, the idea was to reduce bloat, but I don't think we ever measure that. I'm guessing in your case that it's forcing the compiler to keep some full The main point of #62596 was later removed in #82759, but I don't feel any attachment to the |
This isn't the only instance of "formatting code refuses to be optimized away"; this is just one that I noticed at that time that forced me to rewrite some firmware to avoid calls to
Before |
After patching/accounting for inline asm syntax changes locally and bisecting, my issue as described is fixed by 599a03c. This is an LLVM bump, so out of curiosity I bisected to find the relevant patch by @nikic which fixes the bloat (I can't find LLVM commit 4796b4a on Github). Even with Closing as resolved/not Rust's problem. But if the issue comes back, I have a hint of where to look. |
Regression found in the compiler
searched nightlies: from nightly-2019-03-27 to nightly-2019-09-04
regressed nightly: nightly-2019-07-27
searched commits: from 890881f to c43753f
regressed commit: c43753f
source code: https://github.com/cr1901/msp430-size
Instructions
git clone https://github.com/cr1901/msp430-size
. Use commitc32d01b
specifically.just bisect
, or alternativelycargo-bisect-rustc --script=./test-regress.sh --preserve-target --preserve --start=2019-03-27 --end=2019-09-04 --with-src --with-cargo
. The bisector will usetest-regress.sh
to look for size differences between two configurations of themin.rs
example. Contents oftest-regress.sh
are reproduced below for convenience.Error
The example
min.rs
in msp430-size can be built in two configurations:min.rs
example.Because LTO is enabled, I would expect both these configurations to optimize down to the same final binary size. However, using an extern bare_metal crate, especially the
CriticalSection
type,causes
RefCell
trait objects to be left behind forcore::result::unwrap_failed()
.Because the panic handler is an infinite loop, the formatting code left behind is in fact not used, and I believe the formatting code and
RefCell
panic strings should be optimized away as dead code. Because msp430 is size-sensitive, the dead code is a bigger deal than compared to most architectures, sometimes doubling small binary sizes! See the end of COLLAPSIBLE REGRESSION EXAMPLE.COLLAPSIBLE REGRESSION EXAMPLE
Other Context
This bug is still present as of
rustc 1.42.0-nightly (1ed41b072 2020-01-01)
.Inline contents of
test-regress.sh
:The
test-regress.sh
script compiles themin.rs
example in both possible configurations- inline bare_metal and external bare_metal- and compares the output binary sizes. A difference in binary size between the two configurations is considered a failure.The text was updated successfully, but these errors were encountered: