It is. Do note the implications though: * You're taking a reference LLVM can't optimize, so the value won't be placed in a register. * This is only sound to provide as a safe function for owned `MaybeUninit`. Providing it for `&MaybeUninit` is not sound because of things like `MADV_FREE`. **Edit:** It's possible to lift the first restriction specifically for values fitting in register by replacing the asm with: asm!("/* {} */", inout(reg) mymaybeuninit, options(nostack, nomem));

I believe you could do this with a dummy (empty, but takes the memory of interest as a parameter) inline assembly block today. Following the story telling approach to inline assembly, the idea would be something like: asm!("/* {} */", input(reg) &mymaybeuninit, options(nostack)); The story here would be that the inline asm is some unspecified PRNG that sets the memory to something unknown. I _think_ that would be a valid story here.

`options(nostack)` also means that there may be a redzone below the stack pointer, which must not be clobbered as the compiler may be using. I don't think there is a way to avoid this unnecessary `push rax` short of using naked asm instead.

Take a look at this snippet: rust.godbolt.org ### Compiler Explorer - Rust (rustc 1.85.0) #[unsafe(no_mangle)] pub(crate) unsafe fn exec_to_task() { unsafe { core::arch::asm!( "push rbp", "push rbx", "nop", "pop rbx", "pop rbp", out("r12") _, ... The compiler generates unnecessary stack manipulation code (`push rax` and `add rsp, 8`). IIUC the compiler does it to align stack pointer for an assembly block which may use stack (i.e. when we do not provide `options(nostack)`), but in this case the stack gets aligned by the clobbered registers, so the stack is already properly aligned. Is there a way to work around this? Unfortunately, I can not use `options(nostack)` since I need to clobber LLVM-reserved registers (`rbp` and `rbx`) and can not be done with `out(reg) _`.

CAD97: > This operation is not `freeze`, though, although you could use it as `freeze`. So this example is better? #[repr(C)] #[repr(align8)] pub struct Foo { a: u32, b: u8, } pub fn freeze(x: &Foo) -> u64 { unsafe { let r: u64; core::arch::asm!( "mov {1}, qword ptr [{0}]", in(reg) x, out(reg) r, options(nomem, nostack, preserves_flags), ); r } } Most programmers expect that `asm!` blocks exist outside of the AM. The only connection between them is input/output registers and `options`, everything else is just a black box (well, there are also some extremely annoying technicalities like needing to enable target features if you use certain instructions, but they are not important here). Unfortunately, stuff like creating `&mut [u8]` references to an uninitialized memory by freezing is tied closer to AM since because of `MADV_FREE` such memory may observably break assumptions used during optimizations. Doing so probably at the very least would require "touching" memory pages before returning the reference. There was also a somewhat similar example I encountered recently: Reading and erasing bits outside of an allocation in inline asm Unsafe Code Guidelines > RISC-V has an annoying peculiarity in respect of misaligned operations. Technically, it allows misaligned loads using the usual scalar load/store instructions, but the ISA spec does not make any particular guarantees about it. It can run fine, be "extremely slow" (exception trapping by OS and subsequent emulation), or even can result in a fatal exception. Even with the new Zicclsm extension misaligned operation can still be "extremely slow". And there are no extensions (neither existing, nor pla… It's unclear how it's better to formalize it, but these tools exist and some programmers rely heavily on them in practice.

So, is this UB? pub fn freeze(x: MaybeUninit<u64>) -> u64 { unsafe { let r: u64; std::arch::asm!( "// {}", inout(reg) x => r, options(nomem,nostack,preserves_flags), ); r } }