4 ms·
I could be wrong since I am not a Rust developer but I do not think the MIR changes 9 times per year. I would imagine most releases do not touch the MIR these d
by jeltz 7y ago
I could be wrong since I am not a Rust developer but I do not think the MIR changes 9 times per year. I would imagine most releases do not touch the MIR these days.
- est31 7y agoYou'd still have to do the releases in a separate schedule from the main gcc releases, something that the gccgo compiler doesn't do.
- jeltz 7y agoI think we might be talking past each other, because I never claimed otherwise. My point was that LLVM-IR is not a solution to anything becase LLVM-IR would have the same problem, LLVM has a separate release schedule from gcc. I think using the MIR is the best alternative which does not require writing and maintaining a separate frontend from rustc.
- est31 7y agoI thought your reply was referring to the idea mentioned by cbmuser to have a rust frontend in the proper GCC project. Because then you are bound by the release schedule of GCC. Of course one can think about separate projects like the gcc-rust one where you can have whatever release schedule you want. But then it'd be a separate project building on GCC and not a part of the larger GCC project itself. LLVM having a separate release schedule from rustc isn't a problem. rustc can miss out an LLVM release without problem. A rustc 1.35.0 compiled with LLVM 5 can compile a rustc 1.36.0 compiled with LLVM 7. However, GCC can't miss out releases. The rustc 1.36.0 frontend needs at least a 1.35.0 frontend to compile itself. And most Rust programs in the ecosystem work with rustcs compiled with older LLVM releases, but most Rust programs that have dependencies do need newer rustc releases. As for stability of MIR: currently I think MIR is serialized to disk in a glorified mmap way. Basically following the Rust memory representation. It's great if both the creator of the MIR as well as the part that reads the MIR are written in Rust. Furthermore, there are libraries about how memory layout should look like that are provided to codegen backends. Those libraries are written in Rust and not really usable outside of Rust. So currently unless someone serializes MIR using e.g. bincode and provides C bindings for those layout libraries, there are good reasons to write the codegen backend in Rust itself, at least the part that translates MIR to the next stage. In this fashion, LLVM IR is different as it allows a multitude of languages to communicate with it.
- fluffy87 7y agoLLVM-IR is not properly specified, it changes significantly every 6 months (and even faster), and Rust exploits that