
GCC-Rust: Rust frontend for GCC - pcr910303
https://github.com/sapir/gcc-rust/tree/rust
======
cbmuser
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-
> th...](https://www.bountysource.com/issues/80706251-m68k-convert-the-
> backend-to-mode_cc-so-it-can-be-kept-in-future-releases)

> [2] [https://www.bountysource.com/issues/84630749-avr-convert-
> the...](https://www.bountysource.com/issues/84630749-avr-convert-the-
> backend-to-mode_cc-so-it-can-be-kept-in-future-releases)

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

~~~
cbmuser
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
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
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.

------
kibwen
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).

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

~~~
metalforever
Sega genesis development

~~~
ungzd
Also, GCC has Xtensa ISA used on ESP8266/ESP32.

~~~
sanxiyn
LLVM Xtensa port is in progress: [https://github.com/espressif/llvm-
xtensa](https://github.com/espressif/llvm-xtensa)

~~~
ajross
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.

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

~~~
sanxiyn
mrustc has a new frontend independent of rustc. This one reuses rustc
frontend, just substituting GCC backend.

~~~
dathinab
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
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).

------
Avi-D-coder
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
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
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-
compile...](https://hub.packtpub.com/introducing-innative-an-aot-compiler-
that-runs-webassembly-using-llvm-outside-the-sandbox-at-95-native-speed/)

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

~~~
ajross
For the same reason that clang/llvm is a thing and important?

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

~~~
etaioinshrdlu
GCC has a reputation of having confusing architecture. It is a very hard
project to work on. LLVM is typically considered cleaner and more
understandable. GCC is known to have still in 2019, a rather slight
performance benefit. LLVM also has a stable IR named LLVM itself, while GCC
refuses to do so over the decades for political and strategic reasons.

~~~
gioele
> LLVM also has a stable IR named LLVM itself,

LLVM's IR is not stable by design. [1, 2]

[1] [http://lists.llvm.org/pipermail/llvm-
dev/2016-February/09487...](http://lists.llvm.org/pipermail/llvm-
dev/2016-February/094877.html) [2]
[http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-
compa...](http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-
compatibility)

> while GCC refuses to do so over the decades for political and strategic
> reasons.

That was a long time ago. Since GCC 4.5 (released in 2010) GCC supports
external plugins. [3,4] These plugins, like the rest of GCC, use GENERIC and
GIMPLE as their IR.

[3]
[https://gcc.gnu.org/gcc-4.5/changes.html](https://gcc.gnu.org/gcc-4.5/changes.html)
[4]
[https://gcc.gnu.org/onlinedocs/gccint/Plugins.html](https://gcc.gnu.org/onlinedocs/gccint/Plugins.html)

