3 ms·

I have talked to GCC developers about integrating a Rust frontend and they said, the main blocker is the fact that the language specification isn't stable and a

I have talked to GCC developers about integrating a Rust frontend and they said, the main blocker is the fact that the language specification isn't stable and a fast moving target. As long as the Rust language specification isn't stable, GCC's Rust implementation would just fall behind all the time. As an alternative, it has been suggested providing a GCC frontend for the LLVM-IR language which is generated by the Rust compiler since that specification is stable. If Rust's specification becomes stable at some point, it would probably a good idea to start a Bountysource campaign (like we recently did for the m68k [1] and AVR backends [2]) to help the Rust frontend brushed up and ready for being merged into the GCC source tree. > [1] https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases https://www.bountysource.com/issues/80706251-m68k-convert-th... > [2] https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases https://www.bountysource.com/issues/84630749-avr-convert-the...

sanxiyn 7y ago
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.
jeltz 7y ago
I do not think that LLVM-IR is stable either, so I do not think that is a good option. I think this project does the right thing by using the Mir which while not stable either should be more stable than Rust and not any worse than LLVM-IR, while retaining more high level information (e.g. generating LLVM-IR loses MIR's knowledge of restrict).
- est31 7y ago
  I think the instability the GCC devs are concerned about is the release schedule. Rust has 9 releases per year while GCC has 4-5 releases. Unless you update your compiler quickly, you won't be able to use much of the crates.io ecosystem as crates are quick at requiring a new compiler version. Often the implementation of a new language feature is still getting last-minute fixes up to 6 weeks before the release, and sometimes even after that beta period. Compare that to C/C++ which has new releases every 3 years. A compiler that only supports C++14 is still perfectly usable for most C++ codebases out there. In fact, Godot engine still hasn't migrated to C++11 yet, and it's no exception from the norm at all. Even if your compiler has parity with Rust 1.31, released one year ago, you'll have trouble with most projects as even if the project itself doesn't depend on newer compiler releases, one of the transitive dependencies will.
  - 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 ago
      You'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 ago
        I 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.
oconnor663 7y ago
Were you able to get a sense of what counts as stable in this case? Is it about the rate at which new features are added, or more about keeping old code working?
- _bxg1 7y ago
  I believe all old Rust code is kept 100% compatible with compiler updates. It's more about new features being added to the language at a rapid clip compared to languages like C++.
  - mathw 7y ago
    That will slow down I'm sure, but the Rust developers and users are aware of a number of things which are still holding the language back and need to be designed and implemented in the next few years. Big functionality stuff and usability stuff. But also a lot of work on the tooling and ecosystems which won't have anything to do with any language changes. But I would expect in a few more years we'll see the rate of Rust language change will be significantly lower.
deleted 7y ago
[deleted]

sanxiyn 7y ago

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.

jeltz 7y ago

I do not think that LLVM-IR is stable either, so I do not think that is a good option. I think this project does the right thing by using the Mir which while not stable either should be more stable than Rust and not any worse than LLVM-IR, while retaining more high level information (e.g. generating LLVM-IR loses MIR's knowledge of restrict).

est31 7y ago
I think the instability the GCC devs are concerned about is the release schedule. Rust has 9 releases per year while GCC has 4-5 releases. Unless you update your compiler quickly, you won't be able to use much of the crates.io ecosystem as crates are quick at requiring a new compiler version. Often the implementation of a new language feature is still getting last-minute fixes up to 6 weeks before the release, and sometimes even after that beta period. Compare that to C/C++ which has new releases every 3 years. A compiler that only supports C++14 is still perfectly usable for most C++ codebases out there. In fact, Godot engine still hasn't migrated to C++11 yet, and it's no exception from the norm at all. Even if your compiler has parity with Rust 1.31, released one year ago, you'll have trouble with most projects as even if the project itself doesn't depend on newer compiler releases, one of the transitive dependencies will.
- 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 ago
    You'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 ago
      I 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.

oconnor663 7y ago

Were you able to get a sense of what counts as stable in this case? Is it about the rate at which new features are added, or more about keeping old code working?

_bxg1 7y ago
I believe all old Rust code is kept 100% compatible with compiler updates. It's more about new features being added to the language at a rapid clip compared to languages like C++.
- mathw 7y ago
  That will slow down I'm sure, but the Rust developers and users are aware of a number of things which are still holding the language back and need to be designed and implemented in the next few years. Big functionality stuff and usability stuff. But also a lot of work on the tooling and ecosystems which won't have anything to do with any language changes. But I would expect in a few more years we'll see the rate of Rust language change will be significantly lower.

deleted 7y ago

[deleted]