Generally speaking, the Rust language is quite rich, so it's difficult to for the computer to reason about performance, but easy for it to reason about the high-level semantics. On the other end, the LLVM 'assembly' is very primitive, so it's easy to reason about performance, but not in a way that would preserve the desired semantics.
An intermediate language allows you to describe the high-level semantics in a more primitive form, so it is easier to both manipulate and reason about while preserving the high-level semantics. In this case (as far as I understand it,) MIR needs to be as primitive as possible while still modeling Rust's scoping, safety, and type rules. This is an optimization design pattern that occurs quite frequently in practice.
"but easy for it to reason about the high-level semantics."
Is it? Does it make it possible to argue about such things as that mappings can be fused, for example? I keep wondering about the possibility of very-high-level algebraic transformations of programs (although admittedly, this could be shifted into some kinds of CASE tools instead).
It makes it easy to verify that the high-level semantics are only those allowed by the language. It's fairly easy to look at an AST and tell if it is a legal construct in your language.
>Is it? Does it make it possible to argue about such things as that mappings can be fused, for example?
It makes it possible to know that you are "fusing mappings." In the assembly language, you would have a hard time knowing that this is what you were doing, since it communicates semantics with too much granularity.
An intermediate language allows you to describe the high-level semantics in a more primitive form, so it is easier to both manipulate and reason about while preserving the high-level semantics. In this case (as far as I understand it,) MIR needs to be as primitive as possible while still modeling Rust's scoping, safety, and type rules. This is an optimization design pattern that occurs quite frequently in practice.