Skip to content
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

core::fmt fails to optimize on arm-none-eabi #43369

Open
therealprof opened this issue Jul 20, 2017 · 0 comments
Open

core::fmt fails to optimize on arm-none-eabi #43369

therealprof opened this issue Jul 20, 2017 · 0 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. I-heavy Issue: Problems and improvements with respect to binary size of generated code. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. WG-embedded Working group: Embedded systems

Comments

@therealprof
Copy link
Contributor

therealprof commented Jul 20, 2017

While generating code for an Cortex-M0 I noticed that using core::fmt to generate printable output generates extremely bloated code, even when just using a plain string as format.

According to @rkruppe on IRC this is most likely due to a missed elimination of dead code by LTO.

A stripped down example can be found here:
https://gist.github.com/anonymous/7cfc8b881fcb8fdc792428dd772502cb

The generated assembly is here:
https://gist.github.com/anonymous/9cfa48e53e3b1c8ba1ddb69f8ae3ea3b

I also have an example (serial_slow_helloworld) in this repo https://github.com/therealprof/stm32f042.git . xargo build --release --examples will create a binary demonstrating the problem.

This happens for me with:

rustc 1.20.0-nightly (8f1339af2 2017-07-16)
binary: rustc
commit-hash: 8f1339af2e5d1b33ec9ee3c8a3c531bcd61770fc
commit-date: 2017-07-16
host: x86_64-apple-darwin
release: 1.20.0-nightly
LLVM version: 4.0
@Mark-Simulacrum Mark-Simulacrum added I-slow Issue: Problems and improvements with respect to performance of generated code. C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Jul 26, 2017
@jonas-schievink jonas-schievink added I-heavy Issue: Problems and improvements with respect to binary size of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. WG-embedded Working group: Embedded systems labels Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. I-heavy Issue: Problems and improvements with respect to binary size of generated code. I-slow Issue: Problems and improvements with respect to performance of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. WG-embedded Working group: Embedded systems
Projects
None yet
Development

No branches or pull requests

3 participants