Pre-RFC: optimise(size) and optimise(no) attributes

[rkruppe]

It is obvious to me that we need such knobs, and attributes are the natural way to expose them. It will also be trivial to implement since LLVM has matching attributes already.

The only open question for me is bikeshedding: I think we’ll also (in addition to, not instead of this) want some control over specific optimizations like loop unrolling, automatic vectorization, and annotating individual calls as cold. It would be good if the attribute name/format chosen was forward compatible with this,

[Ixrec]

I understand the need for #[optimise(size)] on specific items in size-constrained embedded environments, but what’s the use case for #[optimise(no)]?

[petrochenkov]

what’s the use case for #[optimise(no)]?

Working around optimizer bugs mostly? Or de jure correct optimizer behavior breaking you code because it relies on UB (mostly relevant for C/C++).
Imagine you are porting a large codebase from one compiler version to another and the new version contains… surprises.

[rkruppe]

but what’s the use case for #[optimise(no)]?

Even when everything is working correctly, there are good reasons for disabling optimizations in some parts of your code:

• Improved debug info when you debug in release mode (all but the lowest optimization level tends to make a total mess of it, and even mild optimizations can impact debug info quality somewhat).
• You found that the optimizer takes a lot of time for no/little gain on some part of your code (arguably a bug, but still needs working around)
• The optimizer does improve performance, but the code is rarely used so you don’t want to spend time on optimizing it (while still optimizing everything else)

[mark-i-m]

I would prefer #[optimize(none)] or #[optimize(never)] . no looks like “number” or something.

[HadrienG]

+1 for optimize(never) due to consistency with inline(never)

[repax]

what’s the use case for #[optimise(no)]?

When implementing security-sensitive algorithms compiler optimisations are often disabled so that asymmetries are avoided. These might otherwise be used in side-channel attacks.

[mark-i-m]

Also debugging. Sometimes I want an otherwise optimized binary, but for one function, I want to step through the assembly.

[vadimcn]

Also debugging. Sometimes I want an otherwise optimized binary, but for one function, I want to step through the assembly.

For this one, a module-level attribute might actually be better.

[comex]

Can we also have an #[optimize(always)] to increase rather than decrease optimization level? Useful for hot loops involving, say, long chains of iterator methods, which the optimizer can condense down into near-optimal machine code, but are incredibly inefficient when it’s off.

[HadrienG]

Considering that “optimize” can mean many different things (unrolling, inlining, branch predictor hinting…), I would spontaneously prefer more focused optimization hints (like we already have), in addition to perhaps some support for profile-guided optimization in rustc.

[nagisa]

Can we also have an #[optimize(always)] to increase rather than decrease optimization level? Useful for hot loops involving, say, long chains of iterator methods, which the optimizer can condense down into near-optimal machine code, but are incredibly inefficient when it’s off.

Sadly, no. There are a few angles to this answer, one of which is that property of optimisation is a whole-crate one – optimisation does not only optimise within a function, but also across functions as well (inlining is such an example of cross-function optimisation). For e.g. modules such attribute would make a lot of sense, but LLVM doesn’t currently expose an attribute to achieve that, so workarounds like translating the module into a separate object/codegen-unit would be necessary.

For this one, a module-level attribute might actually be better.

That is a feasible extension to the current proposal, yes.

Would #[optimize(size)] have any effect on monomorphization (i.e: inhibiting it)?

I don’t think, not currently at least. Control of monomorphisation is already pretty explicit in Rust (i.e. it is up to you if you use a banana<T>(t) or banana(&t), and I don’t think it would be beneficial at all for this attribute to implicitly alter the current behaviour.

[comex]

Sadly, no. There are a few angles to this answer, one of which is that property of optimisation is a whole-crate one – optimisation does not only optimise within a function, but also across functions as well (inlining is such an example of cross-function optimisation). For e.g. modules such attribute would make a lot of sense,

I don’t think it makes sense to associate codegen options with a construct that in Rust is supposed to be just for scoping.

but LLVM doesn’t currently expose an attribute to achieve that, so workarounds like translating the module into a separate object/codegen-unit would be necessary.

Mm, this is too bad, and indeed it seems that Clang doesn’t support the attribute-optimize GCC extension you mentioned under prior art. Nevertheless, that workaround doesn’t seem infeasible at all, though it would be more complicated than just exposing optsize and optnone.

[nagisa]

Oh, right. Another point to more precise optimisation attributes would be the very likely future addition of branch weights, which would be specified on the enum variants and/or match arms.

[gnzlbg]

Are fast math flags completely orthogonal to these, or do you expect to expose those via these attributes?

[sunfishcode]

optimize(no) is a very implementation-oriented directive. It’d be interesting to see how practical it would be to capture intent instead. Addressing the use cases raised here:

When implementing security-sensitive algorithms compiler optimisations are often disabled so that asymmetries are avoided. These might otherwise be used in side-channel attacks.

LLVM doesn’t guarantee that optnone will disable all optimizations. As one example, IPSCCP and other interprocedural optimizations can move code out of an optnone function into a non-optnone function, and noinline doesn’t disable them. As another, fast-isel sometimes falls back to selectiondag-isel, and selectiondag-isel does some optimizations automatically. If you’re doing crypto or similar and really need to be sure about timings, perhaps we should talk something like #[timing_sensitive] so that we can have a conversation with implementors about what’s needed to actually implement that reliably.

Imagine you are porting a large codebase from one compiler version to another and the new version contains… surprises.

and

You found that the optimizer takes a lot of time for no/little gain on some part of your code (arguably a bug, but still needs working around)

Thought experiment: what if you required the attribute to have a compiler identifier/version? Something like #optimize(no, LLVM, 4.3), which would only disable optimizations for a specific compiler/version (or perhaps range of versions)? That might discourage these attributes from applying in contexts where the original intent doesn’t apply.

Improved debug info when you debug in release mode (all but the lowest optimization level tends to make a total mess of it, and even mild optimizations can impact debug info quality somewhat).

There are ways to do optimization that don’t disrupt debugging, eg. work on the -Og flag, that optimize(no) would preclude. Would something like #[single_step_debugging], capture the intent here?

The optimizer does improve performance, but the code is rarely used so you don’t want to spend time on optimizing it (while still optimizing everything else)

Rust already covers this with #[cold].

[Ixrec]

Maybe this is a silly question, but it seems like for #[optimize(never)] to be a meaningful attribute we have to agree what “unoptimized code” means, which seems a lot more subtle than “small memory footprint” or “don’t run the optimization passes”. If a disagreement arose as to whether some sequence of assembly instructions was a correct compilation of some code with #[optimize(never)] (I assume crypto people will file bug reports like this), it’s not obvious to me how we’d determine who’s right. For instance, if the hardware has 50 different instructions that could be used for addition, and the compiler happens to choose lea or whatever when compiling 2+2, is that “optimized” compared to the boring, bogstandard add instruction?

Judging by the responses my last post got, it feels like #[optimize(never)] is sort of like a combination of #[preserve_debuginfo], #[inline(never)], #[timing_sensitive] and #[opt_level(0)]. That last one would be an actual compiler knob where we just accept there are no firm semantic guarantees, but the other three are specific enough that I can imagine getting a reasonable consensus on what does or doesn’t qualify as a miscompilation.

[comex]

@sunfishcode mentioned -Og, but just for the record, here’s how GCC documents it:

Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.

In Clang, -Og is currently a synonym for -O1, but according to the documentation, “In future versions, this option might disable different optimizations in order to improve debuggability.” I’m not sure how well the current behavior upholds the goal of not interfering with debugging.

This seems like something rustc should support as an argument to -C opt-level (which already supports 0-3, s, and z).

As for an attribute, perhaps something like #[optimize(debugging)]? For now it could just be translated to optnone – even though that brings the optimization level to the equivalent of -O0 rather than -O1 – but with the potential to do better in the future. Alternately, the idea of using separate codegen units for functions with optimization attributes, which was previously suggested as a hack to support #[optimize(always)], could also be used here…

In any case, I do think there should also be an #[optimize(never)], for when you just know better than the compiler

[nagisa]

LLVM doesn’t guarantee that optnone will disable all optimizations

That’s true, and I don’t think optimise(none) is applicable for the crypto use-case.

Thought experiment: what if you required the attribute to have a compiler identifier/version? Something like #optimize(no, LLVM, 4.3), which would only disable optimizations for a specific compiler/version (or perhaps range of versions)? That might discourage these attributes from applying in contexts where the original intent doesn’t apply.

That’s an interesting suggestion, but is also something that would be prone to “breakage” every LLVM upgrade, if anybody ended up relying on this attribute in any way.

Judging by the responses my last post got, it feels like #[optimize(never)] is sort of like a combination of #[preserve_debuginfo], #[inline(never)], #[timing_sensitive] and #[opt_level(0)].

optimise(no/never) is just opt_level=0 (with the caveat that the cross-function optimisations still may do stuff with it) and inline(never).

This seems like something rustc should support as an argument to -C opt-level (which already supports 0-3, s, and z).

This is something that rustc would have to implement by itself, I believe, by constructing a pass pipeline that would optimise in a debugging friendly manner.

I do not consider optimise(none) to be equivalent to optimise(debugging).

---

All that being said, I don’t see much commentary on optimise(size). Does this mean the optimise(size) is rather fine? I’m considering removing optimise(no/never) from the RFC altogether, so that the attribute that really matters (the optimise(size)) can go through RFC process faster and with less bikeshedding.

[sunfishcode]

All that being said, I don’t see much commentary on optimise(size). Does this mean the optimise(size) is rather fine? I’m considering removing optimise(no/never) from the RFC altogether, so that the attribute that really matters (the optimise(size)) can go through RFC process faster and with less bikeshedding.

Yeah, #[optimize(size)] is much more about intent. Thinking about it a little more though, I do have a few more questions.

When should users use it?

If someone starts with “I care about code size”, I assume the next step should generally be “so I use -C opt_level=s”, rather than “so I put #[optimize(size)] all over my code base”. And for library maintainers starting with “my users care about code size”, “so they should use -C opt_level=s” is probably a better starting point than “so I use #[optimize(size)] for them”.

How does it interact with opt_level?

If you put #[optimize(size)] in your Rust code and then compile it with opt_level=0, which one should win? How about opt_level=z?

Here’s a possible approach:

• Both opt_level=0 or opt_level=z override any #[optimize(size)] directives in the code.
• #[optimize(size)] overrides opt_level=1, 2, or 3.

Do you want a #[optimize(speed)] too?

Similar to how you sometimes want to set opt_level=2 but override it to optsize for individual functions, sometimes you might want to do the inverse: set opt_level=s and override it to optimize for speed in individual functions.

The questions above would apply here too. Users that care about performance probably shouldn’t default to putting #[optimize(speed)] all over their codebase. And, you might want opt_level=0 to override #[optimize(speed)].