12 ms·

GCC-Rust: Rust frontend for GCC

288 points by pcr910303 7y ago

d33 7y ago
No mention of mrust in README. How do those two compare?
- sanxiyn 7y ago
  mrustc has a new frontend independent of rustc. This one reuses rustc frontend, just substituting GCC backend.
  - dathinab 7y ago
    As far as I remember mrustc is not a full rust compiler/frontend, I.e. it is only usable with rust code which had be "proven" to be valid/correct rust by another compiler so you can't really use it for development. It's still useful for bootstrapping rustc as it's a rust compiler not written in rust. It probably can also be useful to compiler rust for some exotic hardware architecture which had no llvm support.
    - littlestymaar 7y ago
      That's correct. Moreover, it's only attempting to compile rustc. Which means it could be completely broken for some other existing rust code. It is not recommended to use it for anything else than bootstrapping rustc (but this is already an incredible achievement).
shmerl 7y ago
Would be interesting to have a fully functional Rust compiler that's not based on llvm.
- gobins 7y ago
  Not likely, as the community is trying to get Rust to get ISO 26262. If they changed the compiler and they will have a whole lot more work to get it certified.
  - sanxiyn 7y ago
    Unrelated. gcc-rust can be developed while rustc is ISO 26262 certified.
    - gobins 7y ago
      Out of curiosity, why would the community maintain two compilers. Wouldn’t that be double the work?
      - EliRivers 7y ago
        You mean like LLVM and GCC? Both compilers for C and C++ (and a lot more with various front ends). I can only imagine they're both maintained because people enjoy working on them and find them interesting projects to develop. When I find something interesting to work on, I certainly don't care that someone else is doing something similar somewhere else.
        lmm 7y ago
        LLVM got where it is primarily because of GCC's licensing (and because GCC's design is deliberately compromised to support that licensing). It's unlikely that LLVM would have been maintained otherwise, and I would expect GCC to fall by the wayside in due course.
        EliRivers 7y ago
        I would expect GCC to fall by the wayside in due course This currently shows no sign of happening. What do you expect to change such that this happens? It's unlikely that LLVM would have been maintained otherwise Again, why? You're making this assertion as if it's fact, but there are a huge number of maintained pieces of software that do the same task as other maintained pieces of software. A great many pieces of software exist that didn't even get started until after similar software was already established. Do you have any logic behind your thinking beyond the fact that they're two pieces of software that do similar tasks?
- metalforever 7y ago
  Sega genesis development
  - cbmuser 7y ago
    And Amiga, Atari, 68k-Macintosh etc. FWIW, there is an out-of-tree m68k backend for LLVM [1]. I have already done some experimental work on Rust for m68k based on this backend [2]. > [1] https://github.com/M680x0/M680x0-llvm/ https://github.com/M680x0/M680x0-llvm/ > [2] https://github.com/glaubitz/rust/tree/m68k-linux https://github.com/glaubitz/rust/tree/m68k-linux
  - ungzd 7y ago
    Also, GCC has Xtensa ISA used on ESP8266/ESP32.
    - sanxiyn 7y ago
      LLVM Xtensa port is in progress: https://github.com/espressif/llvm-xtensa https://github.com/espressif/llvm-xtensa
      - ajross 7y ago
        Lots of things are "in progress" (including rust support for gcc code generation, heh). But gcc has production-ready, mature backends for a ton of architectures that LLVM doesn't. It's a real feature.
- rapsey 7y ago
  Cranelift may become that in the future.
  - kibwen 7y ago
    Although note the Cranelift backend has quite different goals from GCC and LLVM, being optimized for compiler speed over runtime performance, and is very unlikely to support many of the obscure backends that GCC can target.
cschep 7y ago
curious why people want this? I was under the impression that llvm is better than gcc?
- kyllo 7y ago
  Better how? There are plenty of benchmarks showing that gcc's optimizations are more performant than llvm's.
  - saagarjha 7y ago
    And here are plenty that support the converse ;) I don't think there's anything that points to one being definitively better than the other in performance.
    - vunie 7y ago
      >And here are plenty that support the converse Could you site sources please?
  - StreamBright 7y ago
    Like the one where they turned off null checks? https://joelaro.wordpress.com/2015/09/30/gcc-optimization-fdelete-null-pointer-checks/ https://joelaro.wordpress.com/2015/09/30/gcc-optimization-fd...
    - saagarjha 7y ago
      Clang has this too.
      - StreamBright 7y ago
        Not as much as GCC. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949
        7y ago
rafiaabbasi 7y ago
?
cbmuser 7y ago
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.
kibwen 7y ago
The title is somewhat misleading as to the scope of this project, as this looks to be a project for adding GCC backend support to the existing Rust compiler (though this isn't a criticism, that's exactly the approach that I would take!). The (simplified) way that rustc works is that it translates Rust source code into a custom intermediate language called MIR, does a bunch of analysis and a few optimizations, and at the very end translates MIR to LLVM IR and passes that into LLVM. This project looks to add support for translating MIR to GCC's own IR instead of LLVM IR, allowing it to reuse all the other work that has been done writing rustc. For a from-scratch reimplementation of (most of) a Rust frontend, see mrustc ( https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc ), which is written in C++, and served to demonstrate that (a prior version of) rustc did not feature a reflections-on-trusting-trust attack (via diverse double compilation).
thegerman010 7y ago
Im new to this, but why is this a thing and important?
- ajross 7y ago
  For the same reason that clang/llvm is a thing and important?
Avi-D-coder 7y ago
It seems like it would be easier to make a WebAssembly front end rather than MIR. Just compile rust to WASM and use GCC compile to unusual instruction sets. There might be a small performance hit, but the WASM frontend could be likely be upstreamed into GCC. Why was MIR chosen instead of WASM?
- pornel 7y ago
  WASM is designed for a particular sandbox environment, which currently is 32-bit-only. AFAIK WASM has its own calling conventions and sections, so recompilation back to something that works with platform-specific C would involve difficult guesswork or glue code. MIR is Rust's accurate low-level representation with much more type information, and it's aware of native target's specification, so it can be optimized better, and has better interoperability with native code.
  - Avi-D-coder 7y ago
    I agree with you that there would be glue code and I don't doubt your right that MIR can be optimized more. But rust in the general case is agnostic about 32 vs 64 bit pointers and explicitly targets WASM. I'm not familiar with GCC's IR, but unsandboxed AOT WASM compiled thru LLVM IR is astoundingly fast. > This average benchmark has speed in microseconds and is compiled using GCC -O3 –march=native on WSL. “We usually see 75% native speed with sandboxing and 95% without. The C++ benchmark is actually run twice – we use the second run, after the cache has had time to warm up. Turning on fastmath for both inNative and GCC makes both go faster, but the relative speed stays the same”, the official website reads. > “The only reason we haven’t already gotten to 99% native speed is because WebAssembly’s 32-bit integer indexes break LLVM’s vectorization due to pointer aliasing”, the WebAssembly researcher mentions. Once fixed-width SIMD instructions are added, native WebAssembly will close the gap entirely, as this vectorization analysis will have happened before the WebAssembly compilation step. https://hub.packtpub.com/introducing-innative-an-aot-compiler-that-runs-webassembly-using-llvm-outside-the-sandbox-at-95-native-speed/ https://hub.packtpub.com/introducing-innative-an-aot-compile...

288 points by pcr910303 7y ago

d33 7y ago

No mention of mrust in README. How do those two compare?

sanxiyn 7y ago
mrustc has a new frontend independent of rustc. This one reuses rustc frontend, just substituting GCC backend.
- dathinab 7y ago
  As far as I remember mrustc is not a full rust compiler/frontend, I.e. it is only usable with rust code which had be "proven" to be valid/correct rust by another compiler so you can't really use it for development. It's still useful for bootstrapping rustc as it's a rust compiler not written in rust. It probably can also be useful to compiler rust for some exotic hardware architecture which had no llvm support.
  - littlestymaar 7y ago
    That's correct. Moreover, it's only attempting to compile rustc. Which means it could be completely broken for some other existing rust code. It is not recommended to use it for anything else than bootstrapping rustc (but this is already an incredible achievement).

shmerl 7y ago

Would be interesting to have a fully functional Rust compiler that's not based on llvm.

gobins 7y ago
Not likely, as the community is trying to get Rust to get ISO 26262. If they changed the compiler and they will have a whole lot more work to get it certified.
- sanxiyn 7y ago
  Unrelated. gcc-rust can be developed while rustc is ISO 26262 certified.
  - gobins 7y ago
    Out of curiosity, why would the community maintain two compilers. Wouldn’t that be double the work?
    - EliRivers 7y ago
      You mean like LLVM and GCC? Both compilers for C and C++ (and a lot more with various front ends). I can only imagine they're both maintained because people enjoy working on them and find them interesting projects to develop. When I find something interesting to work on, I certainly don't care that someone else is doing something similar somewhere else.
      - lmm 7y ago
        LLVM got where it is primarily because of GCC's licensing (and because GCC's design is deliberately compromised to support that licensing). It's unlikely that LLVM would have been maintained otherwise, and I would expect GCC to fall by the wayside in due course.
        EliRivers 7y ago
        I would expect GCC to fall by the wayside in due course This currently shows no sign of happening. What do you expect to change such that this happens? It's unlikely that LLVM would have been maintained otherwise Again, why? You're making this assertion as if it's fact, but there are a huge number of maintained pieces of software that do the same task as other maintained pieces of software. A great many pieces of software exist that didn't even get started until after similar software was already established. Do you have any logic behind your thinking beyond the fact that they're two pieces of software that do similar tasks?
metalforever 7y ago
Sega genesis development
- cbmuser 7y ago
  And Amiga, Atari, 68k-Macintosh etc. FWIW, there is an out-of-tree m68k backend for LLVM [1]. I have already done some experimental work on Rust for m68k based on this backend [2]. > [1] https://github.com/M680x0/M680x0-llvm/ https://github.com/M680x0/M680x0-llvm/ > [2] https://github.com/glaubitz/rust/tree/m68k-linux https://github.com/glaubitz/rust/tree/m68k-linux
- ungzd 7y ago
  Also, GCC has Xtensa ISA used on ESP8266/ESP32.
  - sanxiyn 7y ago
    LLVM Xtensa port is in progress: https://github.com/espressif/llvm-xtensa https://github.com/espressif/llvm-xtensa
    - ajross 7y ago
      Lots of things are "in progress" (including rust support for gcc code generation, heh). But gcc has production-ready, mature backends for a ton of architectures that LLVM doesn't. It's a real feature.
rapsey 7y ago
Cranelift may become that in the future.
- kibwen 7y ago
  Although note the Cranelift backend has quite different goals from GCC and LLVM, being optimized for compiler speed over runtime performance, and is very unlikely to support many of the obscure backends that GCC can target.

cschep 7y ago

curious why people want this? I was under the impression that llvm is better than gcc?

kyllo 7y ago
Better how? There are plenty of benchmarks showing that gcc's optimizations are more performant than llvm's.
- saagarjha 7y ago
  And here are plenty that support the converse ;) I don't think there's anything that points to one being definitively better than the other in performance.
  - vunie 7y ago
    >And here are plenty that support the converse Could you site sources please?
- StreamBright 7y ago
  Like the one where they turned off null checks? https://joelaro.wordpress.com/2015/09/30/gcc-optimization-fdelete-null-pointer-checks/ https://joelaro.wordpress.com/2015/09/30/gcc-optimization-fd...
  - saagarjha 7y ago
    Clang has this too.
    - StreamBright 7y ago
      Not as much as GCC. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949
      - 7y ago

rafiaabbasi 7y ago

cbmuser 7y ago

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.

kibwen 7y ago

The title is somewhat misleading as to the scope of this project, as this looks to be a project for adding GCC backend support to the existing Rust compiler (though this isn't a criticism, that's exactly the approach that I would take!). The (simplified) way that rustc works is that it translates Rust source code into a custom intermediate language called MIR, does a bunch of analysis and a few optimizations, and at the very end translates MIR to LLVM IR and passes that into LLVM. This project looks to add support for translating MIR to GCC's own IR instead of LLVM IR, allowing it to reuse all the other work that has been done writing rustc. For a from-scratch reimplementation of (most of) a Rust frontend, see mrustc ( https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc ), which is written in C++, and served to demonstrate that (a prior version of) rustc did not feature a reflections-on-trusting-trust attack (via diverse double compilation).

thegerman010 7y ago

Im new to this, but why is this a thing and important?

ajross 7y ago
For the same reason that clang/llvm is a thing and important?

Avi-D-coder 7y ago

It seems like it would be easier to make a WebAssembly front end rather than MIR. Just compile rust to WASM and use GCC compile to unusual instruction sets. There might be a small performance hit, but the WASM frontend could be likely be upstreamed into GCC. Why was MIR chosen instead of WASM?

pornel 7y ago
WASM is designed for a particular sandbox environment, which currently is 32-bit-only. AFAIK WASM has its own calling conventions and sections, so recompilation back to something that works with platform-specific C would involve difficult guesswork or glue code. MIR is Rust's accurate low-level representation with much more type information, and it's aware of native target's specification, so it can be optimized better, and has better interoperability with native code.
- Avi-D-coder 7y ago
  I agree with you that there would be glue code and I don't doubt your right that MIR can be optimized more. But rust in the general case is agnostic about 32 vs 64 bit pointers and explicitly targets WASM. I'm not familiar with GCC's IR, but unsandboxed AOT WASM compiled thru LLVM IR is astoundingly fast. > This average benchmark has speed in microseconds and is compiled using GCC -O3 –march=native on WSL. “We usually see 75% native speed with sandboxing and 95% without. The C++ benchmark is actually run twice – we use the second run, after the cache has had time to warm up. Turning on fastmath for both inNative and GCC makes both go faster, but the relative speed stays the same”, the official website reads. > “The only reason we haven’t already gotten to 99% native speed is because WebAssembly’s 32-bit integer indexes break LLVM’s vectorization due to pointer aliasing”, the WebAssembly researcher mentions. Once fixed-width SIMD instructions are added, native WebAssembly will close the gap entirely, as this vectorization analysis will have happened before the WebAssembly compilation step. https://hub.packtpub.com/introducing-innative-an-aot-compiler-that-runs-webassembly-using-llvm-outside-the-sandbox-at-95-native-speed/ https://hub.packtpub.com/introducing-innative-an-aot-compile...