This is a reply to Centril's post in the "2020 roadmap post" thread. I'm using "reply as linked topic" to avoid spamming that thread.
Probably, but it's slower due to function call overhead. Kernel use cases often aren't very performance sensitive, but they sometimes are.
For example, the Linux kernel has static keys, which are designed to "allow the inclusion of seldom used features in performance-sensitive fast-path kernel code". How? By runtime patching an inline asm sequence to be either a branch (if the feature is enabled) or a sequence of nops (if the feature is disabled). This way, the overhead when the feature is disabled is essentially zero.
(Arguably this isn't even a "kernel use case" per se; it's a generally applicable technique that happens to be implemented in a kernel. But that doesn't make it any less useful.)
The thing is, assembly files have most of the same stability and specifiability concerns as inline assembly, with the added downside that we have zero control over the system assembler and thus zero ability to help preserve backwards compatibility. As far as those concerns go, I believe that recommending the use of assembly files instead amounts to saying "not our problem" without actually helping users.
That doesn't apply to the Cranelift objection, though. It's valid if you think we'll someday have Cranelift-only builds of rustc without LLVM – otherwise we can just use LLVM to compile functions containing inline asm. For now, I am skeptical that Cranelift will ever get to the point where Cranelift-only builds would make sense from a performance perspective.
In any case, the comment you linked is inaccurate. If Cranelift doesn't want to implement assembly parsing itself, it "just" has to add a mode that writes out its own code as assembly, intersperses the user's inline assembly fragments, and compiles the whole thing using the system assembler. (That's what GCC does for everything it compiles, which helps explain why inline assembly is designed that way.) Implementing that would be a fair amount of work, since it would be a different path from Cranelift's existing code generation pipeline. But it would be both less difficult and less risky than actually parsing assembly.
And if it turns out Cranelift is unwilling to do that work... why should that disqualify inline assembly from Rust, as opposed to disqualifying Cranelift?