riscv: deprecate intrinsics that cannot be used from Rust

[RalfJung]

This is the RISC-V version of #1454.

[rustbot]

r? @Amanieu

(rustbot has picked a reviewer for you, use r? to override)

[Amanieu]

Since these are still unstable, do we want to just delete them instead of deprecating them?

[RalfJung]

That would be fine for me, we might want to consult with some RISC-V stakeholders. Cc @coastalwhite (not sure whom else to ping)

Also, we should have some place to document why they are missing.

[coastalwhite]

I think these instructions can be deleted. The riscv crate which is maintained by the Rust Embedded people also has them, and they just implement the assembly themselves. That crate is kind of standard if you are using these kind of instructions and don't want to touch assembly yourself. I don't really see the point of having these intrinsics in the standard library, especially if they are causing trouble.

This also kind of goes for pause, wfi and fence.i (which btw only exists if the Zfencei extension is present), etc. All of these instructions are available from assembly, and adding them here instead of using the riscv crate does not really create too much value. Maybe we should ping @luojia65 who originally implemented them to see why you might need them in stdarch.

@Amanieu is way more knowledgable about what is proper for stdarch, but I would say remove the Floating-Point CSR instructions.

[RalfJung]

These intrinsics should also be deprecated / deleted from the riscv crate then. Observing exception state or changing rounding modes is fundamentally impossible in Rust (same as in C/C++). You have to do the entire sequence of operations in a single inline asm block, e.g. "change rounding mode, do some math, change rounding mode back".

[bjorn3]

In the context of a kernel you have to set the rounding mode during startup to the default value if the boot protocol doesn't guarantee that it has this value and when switching tasks you have to restore the right floating point configuration for the task you are switching too. Kernels are generally compiled with usage of floating point instructions disabled, so there is no way for the compiler to observe that the rounding mode changed, rather it is effectively just a general purpose register which the compiler is not allowed to clobber, and thus there shouldn't be any UB.

[RalfJung]

Sure there's always some super special situations that are exceptions. Technically this needs guarantees we do not provide (rustc will not synthesize float operations if you don't use any float operations), but practically this will work.

However I assume mostly people using these intrinsics are not currently aware that they have to be in such a super special case or else what they are doing is wrong.

[bjorn3]

Technically this needs guarantees we do not provide (rustc will not synthesize float operations if you don't use any float operations), but practically this will work.

If you enable the soft float abi and disable the floating point instruction target features (as you would for a kernel) then having the compiler emit float instructions would be a miscompilation that can cause crashes or worse.

[RalfJung]

Sure, if the feature is entirely disabled we do promise not to use those instructions.

[bors]

☔ The latest upstream changes (presumably 68b3ddf) made this pull request unmergeable. Please resolve the merge conflicts.

[RalfJung]

Since these are still unstable, do we want to just delete them instead of deprecating them?

I did that now.