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

non-nightly rustc reports opt-level s and z are possible options #47651

Closed
mrhota opened this issue Jan 22, 2018 · 0 comments · Fixed by #50265
Closed

non-nightly rustc reports opt-level s and z are possible options #47651

mrhota opened this issue Jan 22, 2018 · 0 comments · Fixed by #50265
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@mrhota
Copy link
Contributor

mrhota commented Jan 22, 2018

The code around opt-levels indicates only nightly rustc can use opt-level=s or opt-level=z. Non-nightly rustcs should not even report those values as possible options.

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jan 22, 2018
bors added a commit that referenced this issue May 21, 2018
stabilize opt-level={s,z}

closes #35784
closes #47651

### Rationale

Since the lastest LLVM upgrade rustc / LLVM does more agressive loop unrolling. This results in increased binary size of embedded / no_std programs: a hundreds of bytes increase, or about a 7x increase, in the case of the smallest Cortex-M binary cf. #49260.

As we are shooting for embedded Rust on stable it would be great to also provide a way to optimize for size (which is pretty important for embedded applications that target resource constrained devices) on stable.

Also this has been baking in nightly for a long time.

r? @alexcrichton which team has to sign off this?
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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants