Currently, the list of supported opt-levels are exhausitvely 0, 1, 2, 3, s, and z. These are generally fine for most uses, however, both gcc and clang support another reasonable optimization level, -Og, which is "optimize for debugging".
Currently on clang, -Og is equivalent to -O1 (with room to adjust certain optimizations to improve debugging). On gcc, -Og is distinct in that it disables a number of -O1 optimizations which are detrimental to debugging.
rustc could probably start with just making it equivalent to -C opt-level=1, while giving future versions (and other implementations) the options to adjust optimizations, like clang. This would also permit the use of this level in debugging (perhaps not by default, but could be explicitly opted-into using cargo profiles), which could be a benefit for programs that take sigificant time to debug on opt-level=0.
It sounds like you want -g -Copt-level=0? Dunno if we can have a whole separate optimization level, given that 0, 1, 2, 3, s, and z map to LLVMisms mostly. If Clang ever makes -Og do something interesting, then maybe rustc can too.
(I am apprehensive of "gcc does it, so should we" because in my experience managing toolchains, gcc is a veritable font of bad judgement.)
(note: for brevity, the gcc-style option -Ox is used in place of the significantly longer -C opt-level=x, for some x)
Not really. -g is unrelated from -Og, though both are used for debugging. As mentioned, clang makes this equivalent to -O1, but having a stable option would be useful for consumers (who want more than -O0 on debugging because that can become painful), as well as implementors that may have the capability to make -Og differ from -O1. As I mentioned, it also opens it to rustc to improve the debugging experience when using the option, as llvm may become more capable of such fine grained optimization control, as new backends are developed, and as mir optimizations become more capable.
I did mention it was "reasonable", rather than just citing that gcc does it. The primary reason I have for recommending it was for my own implementation (hense why I mentioned "giving ... other implementations the options [sic] to adjust optimizations"), which would otherwise have to put it under -Z extra-opt-levels with other, unsound, optimization settings. As it is a user-visible change, it would have to be cleared by the relevant teams to be available on stable. Also, I'd assume technically all of rustc's optimization levels, except for -Oz, were (indirectly) taken from gcc, since they match those used for clang.
This sounds like a use case that may be served by the promised Cranelift integration (faster but worse codegen, preserving debug info, applying fast optimizations that retain debugger visibility) better than an LLVM opt-level.
Mapping of opt levels to codegen backend is an unresolved discussion, but moot until it's closer to a reality iirc?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.