compiler_fence may emit machine code

[Disasm]

As discovered there compiler_fence produces atomic_fence(ordering, SingleThread) construction, which in turn can produce a non-empty code sequence. In fact, LLVM backends for AVR, PowerPC, RISC-V and Spark do not treat SingleThread fence as something special. At the same time Rust docs tell that "compiler_fence does not emit any machine code".
Seems like Rust misuses this "SingleThread means CompilerBarrier" semantics, but I could be wrong.

[nagisa]

Seems like Rust misuses this "SingleThread means CompilerBarrier" semantics

Yes, it does.

[RalfJung]

So what is the right way in LLVM to emit a compiler barrier that definitely emits no machine code?

[nagisa]

clang++ emits the same LLVM instruction (fence sync_scope("thread")) for std::atomic_signal_fence(std::memory_order_seq_cst); and has the same issue on at least the RISC-V target, despite C++ documentation claiming the same no-instructions guarantee.

This is most likely a bug with the LLVM backends in question, rather than Rust’s lowering to LLVM. However llvm_asm!("" ::: "memory") (or whatever equivalent with the new asm! syntax is) is a plausible workaround to this bug.

[lenary]

I'm working on this from the LLVM side. I'll try to take a generic approach that supports both RISC-V and other targets, but if that doesn't pan out, we'll be looking at a RISC-V only patch in LLVM 12.

[lenary]

Aside: I'm not sure either Rust or C++ can provide or enforce the guarantee that no instructions should be emitted. On OoO cores with relaxed memory models it is almost certain that the compiler will need to insert an instruction to tell the core to ensure all stores/loads are completed before proceeding, even if you don't need to synchronize outside of the currently executing core.

While I think it is probably valid for RISC-V to not emit any instruction, the central semantic guarantee on the memory accesses is preserved by emitting the kind of fence instruction corresponding to the ordering requested, and hence I don't think the current RISC-V implementation is fundamentally incorrect, even if it is inefficient.

[nagisa]

compiler_fence's only purpose is to prevent reordering of reads and writes by the compiler itself. OoO execution at hardware level is entirely out of scope as far as this barrier is concerned.

But yes, if we were to ignore the documentation guarantee, it is not strictly incorrect from functional perspective for it to emit a more strict barrier.

[lenary]

It's not clear to me that the C++ version does exclude OoO execution, even though the rust definition does, but I'm happy to follow that GCC leaves out the fence for RISC-V when compiling atomic_signal_fence. I hope to have a patch ready today, which will introduce a cross-target way of doing this, rather than the ad-hoc single-target ways of implementing compiler barriers that have been implemented to date.