Change:
Added in these options are still unstable, this issue will track their progress to becoming stable!
Also note that is adding Cargo support, currently through and , but as we may want more human readable names.
I don't even think there is a single word that describes what does. As far as I know it was first introduced in clang and selected for its closeness to and connotations of compression, but this doesn't help at all when you need an immediately understandable token in
/ for and for ?
is right, "s" and "z" are not clear at all. I had no idea what "z" even did until I looked it up. it is the same as "s" but without loop vectorisation. According to it is intended to reduce size even further. I like the "size-1"/"size-2" idea.
We are potentially interested in this for Gecko's integration of Rust code, see [1]. We'd need to do more measurements to determine if the performance impact is acceptable though. [1]
thanks for the info! We haven't seen a lot of movement here in awhile and we've got support in Cargo/build scripts now, so I'd like to propose we stabilize this: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [ ] [x] [x] [ ] [ ] [x] [x] [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
IS this properly documented? That can come after we've approved for stability, right?
good point! I think we should definitely make sure it's documented at least in or the various man pages.
yes, that should come before the final PR itself lands though.
It seems like there was an open concern that these tokens (especially for Cargo) aren't very clear. Do we want to take a short at single-word tokens before stabilizing?
I'm not personally motivated to do so as this is such a niche feature it seems like it's not worth the effort, but others may feel differently.
I feel differently! If I change the patch to , and would that be acceptable? Or is it too late since Cargo has already merged and ? If so then we should probably stick with that but they should be properly documented since clearly very few people know what they mean.
I think we're definitely still able to change, we just might have to have a small period of time where we support everything to deprecate s/z
is there any particular reason that, for Cargo, we need more than just ? In practice, the main historical distinction between and was that was OSX-specific, and gave you "definitely, for realz optimize for size." As far as I can tell, Cargo really only needs a way for people to say "I want you to optimize for size, please" and having multiple different versions of "optimize for size" at the Cargo level seems likely to introduce more confusion than help. I propose that we add to Cargo, and not leak and . I think I feel the same way about but don't have as strong of an opinion there.
Sounds plausible to me! In that case sounds like there's work to do, so I'll cancel the FCP fcp cancel
proposal cancelled.
That's not what does, as far as I can tell. According to Clang's manual: Also see . By the way, there is also ! , which is: Sounds like it could be useful. I suggest for that.
I came here because I wasn't sure what -Oz did - now I know. I would like to point out that "size1" and "size2" is not much better, imho. Ok, so there's a size difference. But which one is supposed to be smaller? The bigger number, because it tries more agressively to make it smaller, or the smaller number, for intuitive reasons? I can see the parallel with O1, O2, O3 -increasing optimization for speed, and S1, S2, S3 -increasing optimization for size, but perhaps this should be made more explicit then? We can always keep "s", "o", and so on as shorthand aliases
Hello This seems to have gone to sleep. I mean, the name for it is important, but no discussion seems to be happening for like 9 months ‒ is it likely to move forward? As for me, I'd rather have the feature stabilized (I'm often aiming at devices with chronic lack of storage space), no matter the actual values used. Or is it blocked on anything else beside choosing the right name?
Side note: the crash in only reproduces with -Os (probably an LLVM bug)
Since the lastest LLVM upgrade rustc / LLVM does more agressive ~inlining~ 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. . 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. What can we do to move this forward. Can we at least stabilize "s" on rustc? Cargo already allows in the but requires a nightly toolchain. is this (opt-level) being discussed as part of the Cargo profile revamp?
I think those optimizations have baked long enough that it should be fine to stabilize now personally!

Discussion:
} OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(