Skip to content

Optimize for size #32296

Closed
Closed
@engstad

Description

@engstad

It seems that the compiler doesn't understand -Os (optimize for size):

$ rustc -C opt-level=s -Z no-landing-pads --target thumbv7em-none-eabi -g --emit obj -L libcore-thumbv7em -o main.o ./blink/src/main.rs
error: incorrect value `s` for codegen option `opt-level` - a number was expected

Activity

steveklabnik

steveklabnik commented on Mar 16, 2016

@steveklabnik
Member

As far as I know, yes, this isn't a thing.

engstad

engstad commented on Mar 17, 2016

@engstad
Author

I believe both GCC and Clang support the -Os option, and this is normally an embedded application's default. Support for this in Rust would follow that tradition.

nodakai

nodakai commented on Mar 17, 2016

@nodakai
Contributor

Give this a try:

rustc -C opt-level=3 -C lto -C link-args=-s foo.rs

I guess static linking of libstd is "to blame" for the output size rather than the optimization level.

By the way, Rust FAQ must have an item on the issue of "huge" binary size.

engstad

engstad commented on Mar 17, 2016

@engstad
Author

Embedded systems don't usually include libstd, only libcore. However, for embedded systems (and IoT), size is often more important than speed.

MagaTailor

MagaTailor commented on Mar 17, 2016

@MagaTailor

@engstad, the idea of -Os can be safely decoupled from anything embedded or binary size in general - it used to be a rule that hot C++ code compiled for size ran faster (better fit in cache) than -O3.

So yeah, that would be a welcome addition with benchmarking in mind.

nodakai

nodakai commented on Mar 18, 2016

@nodakai
Contributor

@engstad Are you working on an embedded system already without libstd, and the output binary size is still that important? Well, I tend to agree that smaller binaries are faster to load...

FYI, when I compiled GNU Make with Clang 4.8 x86_64 -Ofast and -Os, the stripped binary sizes were 192 KB vs 175 KB, 10 % difference.

added a commit that references this issue on Mar 22, 2016
16dcdc6
added a commit that references this issue on May 2, 2016

Auto merge of #32386 - brandonedens:llvm_min_size, r=alexcrichton

9a003b0
polarathene

polarathene commented on Jul 5, 2016

@polarathene

@engstad @nodakai I've been looking for up to date information in regards to using Rust with embedded systems such as the Cortex M range of MCU that do not run Linux OS due to lack of resources. Is there any reference/information you can refer me to? I'm aware of Zinc.rs but that is not quite ready yet from what I understand. Are you able to interact with Arduino or mbed libraries?

Are you using Rust freestanding/bare metal or with an RTOS like FreeRTOS/ChibiOS/Zephyr? I've read that for MCU to have Rust working we must avoid using the std lib, @nodakai gives me the impression that higher end MCU do not have to avoid this?

added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Mar 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-frontendArea: Compiler frontend (errors, parsing and HIR)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @steveklabnik@nodakai@engstad@polarathene@MagaTailor

        Issue actions

          Optimize for size · Issue #32296 · rust-lang/rust