stabilize optimize attribute

[veluca93]

View all comments

This commit stabilizes the #[optimize] attribute, which allows for more fine-grained control of optimization levels.

Stabilization report

Summary

Tracking issue: #54882
Reference PRs: rust-lang/reference#2278

cc @rust-lang/lang @rust-lang/lang-advisors @rust-lang/t-compiler

What is stabilized

// Instructs the optimization pipeline to prioritize smaller code size over speed.
#[optimize(size)]
pub fn binary_size_sensitive() {
    // ...
}

// Instructs the optimization pipeline to prioritize execution speed over code size.
#[optimize(speed)]
pub fn performance_critical() {
    // ...
}

// Disables optimizations entirely for this item.
#[optimize(none)]
pub fn debug_only() {
    // ...
}

What isn't stabilized

We might want to allow specifying a per-function optimization level (i.e. #[optimize(level = 3)]). To my understanding, backend support for this is not quite there yet (and this - or other - extensions have consequently not been implemented yet).

Applying the attribute on a module level is also not implemented yet.

Design

Reference

• Description of the new attribute: Stabilize #[optimize] attribute reference#2278

RFC history

• https://rust-lang.github.io/rfcs/2412-optimize-attr.html

Answers to unresolved question

• Should we also implement optimize(always)? optimize(level=x)?

Not yet.

• Should there be any way to specify what global optimization for speed level is used in conjunction with the optimization for speed option (e.g. -Copt-level=s3 could be equivalent to -Copt-level=3 and #[optimize(size)] on the crate item).

Not yet.

Post-RFC changes

The optimize(none) variant was added. The variants above were discussed here: #54882 (comment)

Key points

• #[optimize(none)] implies #[inline(never)] to be effective (#[optimize(none)] should imply #[inline(never)] #136329)
• As with all optimization-controlling flags, the effects on speed and binary size can be hard to predict: Tracking issue for RFC 2412, "The optimize attribute" #54882 (comment)
• Applying the attribute to incompatible items emits an error: Emit an error if #[optimize] is applied to an incompatible item #128458

Nightly uses

The standard library itself uses this attribute in a few places

Implementation

Major part

• Wiring it up to the llvm codegen backend:

  rust/compiler/rustc_codegen_llvm/src/attributes.rs

  Line 416 in c0bb140

  match codegen_fn_attrs.optimize {

• Catching usage on incompatible items: Emit an error if #[optimize] is applied to an incompatible item #128458
• Implementing optimize(none): Add #[optimize(none)] #128657 #[optimize(none)] implies #[inline(never)] #136358 (includes disabling MIR opts)

Coverage

• Basic tests: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/ui/attributes/optimize.rs
• Testing the effect on compilation: https://github.com/rust-lang/rust/blob/c0bb140a37c81cf59a0b40c21c9413059644e294/tests/codegen-llvm/optimize-attr-1.rs

Tool changes

Trivial changes to rust-analyzer to support the new attribute as an inert attribute: rust-lang/rust-analyzer#22511

Type system, opsem

Breaks the AM?

As far as the AM is concerned, this attribute doesn't exist.

Acknowledgments

Most of the work was not done by me, I'm just writing the stabilization report :-)

@nagisa did the initial implementation, @clubby789 implemented optimize(none) and fixed the attribute being allowed in too many places.

Note

Concerns (0 active)

• are-we-happy-wiht-capability-and-scope-of-this-attribute resolved in this comment
• meaning-of-optimize-size resolved in this comment
• explicitly-decide-on-effect-on-nested-functions resolved in this comment

Managed by @rustbot—see help for details.

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 17 candidates

[tgross35]

Given the interactions here, I expect this will need a lang+compiler FCP

@rustbot label +I-lang-nominated +I-compiler-nominated

See some recent discussion about this feature on Zulip #t-lang > status of #[optimize] attribute

[JohnTitor]

Marking as S-blocked given the current status.

[rustbot]

These commits modify tests/rustdoc-json.
rustdoc-json is a public (but unstable) interface.

Please ensure that if you've changed the output:

• It's intentional.
• The FORMAT_VERSION in src/librustdoc-json-types is bumped if necessary.

cc @aDotInTheVoid, @obi1kenobi

[obi1kenobi]

With my cargo-semver-checks hat on: do we expect this attribute to have SemVer implications?

For example, can applying or removing this attribute on an item influence the contexts in which that item may be used without compile errors or other changes that would be considered public-API-breaking?

[veluca93]

With my cargo-semver-checks hat on: do we expect this attribute to have SemVer implications?

For example, can applying or removing this attribute on an item influence the contexts in which that item may be used without compile errors or other changes that would be considered public-API-breaking?

I don't believe this is possible - the attribute should only influence how the compiler optimizes functions, and compiler optimizations should not have any visible effects.

[jieyouxu]

Discussion: hm, I wonder if this attribute deserves an entry in the rustc book (a bit like lint levels), because while sure there's the Reference PR, but this is more like a compiler knob?

View changes since the review

[traviscross]

This is for lang to consider -- what is the intended behavior of #[optimize(..)] to a nested function? Does the attribute's effect "recursively apply"?

In my view, it should work in the same way as #[inline(…)].

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[veluca93]

On the capabilities and scope of the attribute (@nagisa): as you said, I don't believe we can ever give realistic guarantees on what effects those attributes will have - beyond the fact that they do not change the semantics of the program, and that they might affect compiler optimizations -- similarly to the inline attribute, and to most of the contents of the std::hint module. That said, IMO the final decision on this rests on t-lang.

On the meaning of optimize(size) (@nikic): I believe using LLVM's minsize is more likely to match the intent, but IMO having size = minsize makes it more awkward to have also something that maps to optsize (I'd find it more natural to have size, minsize than to have optsize, size). I am personally fine with having size = minsize, but again probably better left to t-lang :-)

On behaviour of nested functions: I agree with @traviscross that it probably should be the same as inline, and as far as I can tell this is indeed the current behaviour.

[joshtriplett]

Leaving aside whether we apply the optimize attribute recursively to nested items, it'd be helpful to know whether it applies recursively to closures. If those are treated the same way, that seems likely to be surprising; I think people would expect the attribute to apply recursively to closures. If the easiest way to do that is to also apply recursively to items, then I think that's what we should do, as closures seem likely to be the common case where it's desired and where it'd be otherwise inconvenient to do.

(Also, can we confirm whether we can write the attribute in a fashion that applies to closures?)

[joshtriplett]

Random bikeshed-color suggestion (for future extension, not derailing what's currently proposed for stabilization):

• optimize(size) = opt-level="z"
• optimize(size,speed) = opt-level="s"

[veluca93]

Leaving aside whether we apply the optimize attribute recursively to nested items, it'd be helpful to know whether it applies recursively to closures. If those are treated the same way, that seems likely to be surprising; I think people would expect the attribute to apply recursively to closures. If the easiest way to do that is to also apply recursively to items, then I think that's what we should do, as closures seem likely to be the common case where it's desired and where it'd be otherwise inconvenient to do.

(Also, can we confirm whether we can write the attribute in a fashion that applies to closures?)

As far as I can tell, it is not (and neither is inline, fwiw).
The attribute can be written as {#[optimize(size)] |x| x} or similar, but that seems to have no effect as far as I can tell. So that probably requires some fixing.

[scottmcm]

This choice should be optimized. We could also map to optsize instead, or we could expect both options. I don't have any specific preference here, I just want to make sure we're making a deliberate decision.

At least from a lang perspective I'd be happy adding things like optimize(min_size) in the future if compiler said they were useful, so if size was s for now and we could add more things for z in future if that would be useful that'd be good for me.

[veluca93]

This choice should be optimized. We could also map to optsize instead, or we could expect both options. I don't have any specific preference here, I just want to make sure we're making a deliberate decision.

At least from a lang perspective I'd be happy adding things like optimize(min_size) in the future if compiler said they were useful, so if size was s for now and we could add more things for z in future if that would be useful that'd be good for me.

my 2c: I prefer #[optimize(size, speed)] over having min_size and size, but I like both.

[traviscross]

For my own part, on the meaning question, I'm happy for optimize(size) to mean "optimize for size at all costs". If, in the future, we want a way to express "optimize for a balance between both size and speed", I'd be happy with optimize(size, speed) for that.

Regarding the degree to which this is a lang question, I think what we intend for an attribute to mean (e.g., "optimize for size at all costs"), and consequently, what we'd write in the Reference about it, is a lang question. How to best implement that, in terms of which flags to apply, is a compiler one. E.g., our docs say that z "often results in larger binaries than s". Compiler would be within its rights if it were to conclude that, on balance, s better achieves the "optimize for size at all costs" intended meaning.

On the other two questions:

One, I still expect this attribute to affect only the item to which it is applied, in the same way as inline and our other codegen attributes. We treat closures as a kind of pseudo-item for this purpose.

If we were to later want to apply this to modules and to functions in a way that it would affect inner items, I'd expect this to be syntactically distinct and to work in the same way with inline. E.g., maybe we'd add an apply(…) (TODO: naming bikeshed) attribute and then write #[apply(inline(always))] fn f() { … } and #[apply(optimize(speed))] fn f() { … }.

Two, on the question of whether we're happy with the capability and scope of this attribute, e.g., that no guarantees can be made about optimize(none), I'm happy with that. As with our other codegen attributes, nobody should rely on these, e.g., to ensure constant-time operation.

[traviscross]

In the lang meeting today, we discussed the three questions raised as concerns:

On the capabilities and scope question, we were all agreed that we're happy to accept the limitations.

On the question of meaning, we were happy with optimize(size) focusing on size optimization and leaving to compiler to determine what that means in terms of the appropriate flags to apply. We discussed how we could later accept optimize(size, speed), if needed, and people seemed generally happy with that.

On the question of whether this applies recursively to inner items, my sense of the meeting was that we were happy for this to land in its current form where it does not apply recursively, but I note @joshtriplett's earlier comment in #157273 (comment), so I'll let him speak to whether he considers application to inner closures something we should discuss and resolve before proceeding.

@jieyouxu: Does that help with the concerns you raised? Once you've resolved those, I'm planning to propose dual FCP merge between lang and compiler.

[veluca93]

FWIW, specifically for closures, I think we should at least make an optimize attribute applied to a closure do something if the closure is not inlined, regardless of whether closures inherit the optimize attribute of the function they live in.

Since often closures are MIR-inlined (I believe!), perhaps having the closure inherit the attribute is the least surprising behaviour - otherwise whether the closure inherits the attribute or not depends on hard-to-control optimizations (of course whether the attribute does something at all also depends on optimizations, but we should at least try to not make the problem worse)

[jieyouxu]

Does that help with the concerns you raised? Once you've resolved those, I'm planning to propose dual FCP merge between lang and compiler.

Yes, unless we still have that closure semantics question to make a deliberate decision on. I was mostly just forwarding important comments as concerns so they're not lost.

@rustbot resolve are-we-happy-wiht-capability-and-scope-of-this-attribute
@rustbot resolve meaning-of-optimize-size
@rustbot resolve explicitly-decide-on-effect-on-nested-functions

[traviscross]

The attribute can be written as {#[optimize(size)] |x| x} or similar, but that seems to have no effect as far as I can tell. So that probably requires some fixing.

FWIW, specifically for closures, I think we should at least make an optimize attribute applied to a closure do something if the closure is not inlined...

As best I can tell, optimize on closures does have effect and seems to work in the way I'd expect (i.e., in the same way as inline). E.g., Godbolt link.

@veluca93: Are we looking at the same thing?

[veluca93]

The attribute can be written as {#[optimize(size)] |x| x} or similar, but that seems to have no effect as far as I can tell. So that probably requires some fixing.

FWIW, specifically for closures, I think we should at least make an optimize attribute applied to a closure do something if the closure is not inlined...

As best I can tell, optimize on closures does have effect and seems to work in the way I'd expect (i.e., in the same way as inline). E.g., Godbolt link.

@veluca93: Are we looking at the same thing?

I think we are looking at similar things, at least - I tried (size) instead of (none) and its behaviour seems a bit less predictable, see https://rust.godbolt.org/z/jGjc51PKn :-)