我可以强制Rust不优化单个函数吗？

Question

I have a function where Rust's/LLVM's optimization fails and leads to a panic (in the release version), while the unoptimized code (debug version) just works fine. If I compare the generated assembly code, I can not even grasp an idea what the optimizer tries to accomplish. (A reason might be that this very function uses inline assembler.)

Is there any way to tell Rust to leave certain functions alone during the optimisation, or do I have to switch off all optimizations?

Here is the specific function:

#[naked]
pub extern "C" fn dispatch_svc(){
    Cpu::save_context();
    let mut nr: u32 = 0;
    unsafe {
        asm!("ldr r0, [lr, #-4]
              bic $0, r0, #0xff000000":"=r"(nr)::"r0":"volatile")
    };
    swi_service_routine(nr);
    Cpu::restore_context_and_return();
}

Answer 1

To the best of my knowledge, Rust has no facilities to specify optimisation levels on anything but the entire crate. Your only workaround would be to compile this function in an individual crate, compile it, and then include it as a pre-compiled dependency. (Normal rust-dependencies are compiled at the optimisation level of the depender)

However: Specifying a different optimisation level for this single function will not solve your problem! Sure, it may work today, but can break again each time the compiler (or optimisation flags) change.

TL;DR : naked functions are deeply unsafe (My respect, you're a braver person than I am!). The only reliable way to use them is to write only one single asm!() block as the entire function body, nothing else. Mixing asm! , normal Rust and function calls like you are doing is effectively Undefined Behaviour (in the scary C/Nasal-Demon sense of the term) No amount of optimisation-tweaking will change this.

---

Naked functions are still unstable until the Rust authors "get it right". As you have discovered, there are many subtle problems with this. Tracking issue for stabilisation here

In the naked-fn RFC , under "Motivation", we find:

Because the compiler depends on a function prologue and epilogue to maintain storage for local variable bindings, it is generally unsafe to write anything but inline assembly inside a naked function . The LLVM language reference describes this feature as having "very system-specific consequences", which the programmer must be aware of.

(emphasis mine)

A little bit lower in the RFC, under unresolved questions , we learn that this is not just a problem for Rust. Other languages also experience problems with this feature:

.. most compilers supporting similar features either require or strongly recommend that authors write only inline assembly inside naked functions to ensure no code is generated that assumes a particular stack layout.

The reason is that all compilers make a LOT of assumptions about how functions are called (keywords: "Caller-Saved Registers", "Callee-saved registers", "Calling convention", "Red zone") . Naked functions don't obey these assumptions, and thus any code a compiler generates is highly likely to be wrong. The "solution" is to not let the compiler generate anything, ie write the entire function by hand in assembly.

As such, the way you are mixing 'normal' code ( let mut nr: u32 = 0; ), function calls ( swi_service_routine(nr); ) and raw assembler in a naked function is unspecified behaviour . (Yes, such a thing exists in Rust, but only in Unstable).

Naked functions cause enough problems that they deserve their own label in the Rust bugtracker. In one of the A-naked issues, we find this comment , by knowledgeable user Tari (among others, author of llvm-sys . He explains:

The actual correctness of non-asm code in naked functions depends on the optimizer and code generator, which in general we cannot make any guarantees about what it will do.

There is also talk about requiring unsafe for naked functions, as they break many of Rust's normal assumptions. The fact that they don't require this yet in all cases is an open bug

---

So, the proper solution to your "optimisation problem" is to stop relying on optimisation at all. Instead, write only a single asm!() block.

For your Cpu::save_context() / Cpu::restore_context_and_return() pair: I can understand the desire for code-reuse. To get it, change those into a macro that inserts the relevant asm!(...) . A concatenation of asm!(...); asm!(...); asm!(...); asm!(...); asm!(...); asm!(...); should be equivalent to a single asm!() .

Answer 2

If you are using cargo, you can tell it not to optimize anything at all, or by levels

cargo optimize