Hacker News Reader

Comment by sievebrain | Hacker News Reader

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.

View on HN

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.

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.

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

(The post has been amended to try to clear this up a bit)

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.

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.

Speaking of comparisons to bytecode, there's currently a student writing a MIR interpreter as part of their research: 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.

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.

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.

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.

Reply on news.ycombinator.com