3 ms·

Since this implementation shares the frontend with rustc, there is no reason it would fall behind.

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 ago
  Yes, 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 ago
    Sounds 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 ago
  If 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 ago
  Most likely yes. This is also the same approach taken by D, with the same frontend being shared across dmd, gdc and ldc.
  - sanxiyn 7y ago
    D 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 ago
        So far the goal is faster debug builds, both in compile times and performance of the generated code.
hsivonen 7y ago
Considering that it's more difficult to install upstream GCC than it is to install upstream rustc, there's ample opportunity for the distro snapshot that users would see to fall behind.

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 ago
Yes, 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 ago
  Sounds 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 ago
If 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 ago
Most likely yes. This is also the same approach taken by D, with the same frontend being shared across dmd, gdc and ldc.
- sanxiyn 7y ago
  D 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 ago
      So far the goal is faster debug builds, both in compile times and performance of the generated code.

hsivonen 7y ago

Considering that it's more difficult to install upstream GCC than it is to install upstream rustc, there's ample opportunity for the distro snapshot that users would see to fall behind.