3 ms·

It's interesting to compare and contrast this against bytecode from other platforms like CIL or JVM bytecode. They're both essentially a kind of compiler IR and

It's interesting to compare and contrast this against bytecode from other platforms like CIL or JVM bytecode. They're both essentially a kind of compiler IR and they allow for incremental compilation, can be interpreted, dynamically manipulated, structed as basic blocks, etc. But MIR is represented using a textual form that still has scoping and which still uses Rust syntax. I can see the appeal. But I wonder how much it complicates working with MIR. You'd need a more complex parser, I guess.

dikaiosune 10y ago
IIUC, MIR has a textual representation, but the compiler works on a control flow graph in memory. I don't think MIR is written to disk and then re-parsed during compilation.
- avita1 10y ago
  My guess is that in the future, source code -> MIR could be cached (on disk) so that whole-program optimization/linking could happen without compiling all of the source to IR.
  - Sean1708 10y ago
    If that were to happen I expect they would devise some sort of bytecode to use, probably with a 1=>1 mapping to the textual representation.
steveklabnik 10y ago
Inside rustc, MIR is a data structure. The outputs you see here are a human-readable export of that, the compiler does not emit text and then re-parse. Projects in Rust, like miri, hook directly into the compiler and use the datastructures as well, they don't parse the output you see here: https://github.com/tsion/miri/blob/master/src/bin/miri.rs https://github.com/tsion/miri/blob/master/src/bin/miri.rs (The post has been amended to try to clear this up a bit)
- sievebrain 10y ago
  That's certainly true today, but other ecosystems have benefited tremendously from tools that are able to work directly with the IR (well, bytecode). Usually to pull off features that can't be expressed directly in the language without huge pain, like continuations, or to do things like profiling. I understand the desire to keep MIR private and avoid needing to stabilise a syntax and feature set for it, but there are benefits to doing so as well.
  - steveklabnik 10y ago
    Yes, but at the time that we actually do stabilize such a thing, we could choose a representation that looks completely different than this one, one that would be easier to parse.
kibwen 10y ago
Speaking of comparisons to bytecode, there's currently a student writing a MIR interpreter as part of their research: https://github.com/tsion/miri https://github.com/tsion/miri . There are some that foresee this being added to the Rust compiler itself, to enable more extensive compile-time constant evaluation.
pcwalton 10y ago
It's kind of a moot point, because MIR never leaves its in-memory representation in normal compilation. (However, that may well change with future improvements to incremental compilation, though the on-disk format will likely never be formally defined and stabilized--it's too much work for little gain.) Surface syntax of the compiler IR isn't particularly important anyway.
- eddyb 10y ago
  Well, actually, we store MIR in crate metadata. However, it's not a special serialization format, just the rustc_serialize infrastructure, i.e. you could also serialize MIR to JSON if you really wanted to.

dikaiosune 10y ago

IIUC, MIR has a textual representation, but the compiler works on a control flow graph in memory. I don't think MIR is written to disk and then re-parsed during compilation.

avita1 10y ago
My guess is that in the future, source code -> MIR could be cached (on disk) so that whole-program optimization/linking could happen without compiling all of the source to IR.
- Sean1708 10y ago
  If that were to happen I expect they would devise some sort of bytecode to use, probably with a 1=>1 mapping to the textual representation.

steveklabnik 10y ago

Inside rustc, MIR is a data structure. The outputs you see here are a human-readable export of that, the compiler does not emit text and then re-parse. Projects in Rust, like miri, hook directly into the compiler and use the datastructures as well, they don't parse the output you see here: https://github.com/tsion/miri/blob/master/src/bin/miri.rs https://github.com/tsion/miri/blob/master/src/bin/miri.rs (The post has been amended to try to clear this up a bit)

sievebrain 10y ago
That's certainly true today, but other ecosystems have benefited tremendously from tools that are able to work directly with the IR (well, bytecode). Usually to pull off features that can't be expressed directly in the language without huge pain, like continuations, or to do things like profiling. I understand the desire to keep MIR private and avoid needing to stabilise a syntax and feature set for it, but there are benefits to doing so as well.
- steveklabnik 10y ago
  Yes, but at the time that we actually do stabilize such a thing, we could choose a representation that looks completely different than this one, one that would be easier to parse.

kibwen 10y ago

Speaking of comparisons to bytecode, there's currently a student writing a MIR interpreter as part of their research: https://github.com/tsion/miri https://github.com/tsion/miri . There are some that foresee this being added to the Rust compiler itself, to enable more extensive compile-time constant evaluation.

pcwalton 10y ago

It's kind of a moot point, because MIR never leaves its in-memory representation in normal compilation. (However, that may well change with future improvements to incremental compilation, though the on-disk format will likely never be formally defined and stabilized--it's too much work for little gain.) Surface syntax of the compiler IR isn't particularly important anyway.

eddyb 10y ago
Well, actually, we store MIR in crate metadata. However, it's not a special serialization format, just the rustc_serialize infrastructure, i.e. you could also serialize MIR to JSON if you really wanted to.