3 ms·
Ah, interesting. But can this implementation actually be built for architectures not supported by LLVM? I looked at the build instructions and the first build s
by cbmuser 7y ago
Ah, interesting. But can this implementation actually be built for architectures not supported by LLVM? I looked at the build instructions and the first build step involves building parts with the standard Rust compiler.
I also just realized that it's not the same backend as the one written by "redbrain" here [1].
> [1] https://github.com/redbrain/gccrs https://github.com/redbrain/gccrs
- sanxiyn 7y agoYes, it's a different attempt from redbrain's. gcc-rust currently needs LLVM to build because that's the only good way to build Rust code, and gcc-rust (unlike, say, mrustc) uses Rust code. Once gcc-rust is on track, Rust code used by gcc-rust can be built by gcc-rust, and LLVM becomes unnecessary.
- cbmuser 7y agoSounds very good. I'll keep an eye on the project. I would love to see such a frontend merged into GCC upstream and I would definitely shell out some money for a Bountysource campaign to support the effort.
- dbrgn 7y agoIf I'm not mistaken, the pipeline is Rust -> MIR -> LLVM -> Binary. The GCC backend probably uses MIR, which is simpler than Rust itself.
- pjmlp 7y agoMost likely yes. This is also the same approach taken by D, with the same frontend being shared across dmd, gdc and ldc.
- sanxiyn 7y agoD comparison is very apt: Rust also would have one frontend with three backends, GCC, LLVM, and its own (Cranelift).
- mwcampbell 7y ago> its own (Cranelift) Interesting. This is the first I've heard of Cranelift being used as anything other than a code generator for wasm runtimes. When would Cranelift be used instead of LLVM, and vice versa?
- amaranth 7y agoSo far the goal is faster debug builds, both in compile times and performance of the generated code.