Rust is an awesome piece of technology but sadly still running on a few architectures (I’m know there’s efforts to add more back-ends to LLVM, but until goes to real hardware can be a long time), so I’m here to question you about invest some effort to create a GCC front-end.
I think it’s important to have multiple implementations of Rust, and to support as many platforms as possible, and as @cuviper suggests, reusing the reference front-end and plugging in a gcc backend may be the most productive short-term path. There is one other project intending to create a new Rust backend, and it’s important that rustc support the use case.
The major blocker is refactoring rustc to support non-LLVM backends, after that it’s just an enormous amount of work.
It’s hard to predict the things that Mozilla will support financially, as there are many sources of funding within Mozilla and they all have their own opinions. I personally think it’s a worthy effort, though the importance of a gcc backend at this time is relatively low compared to other projects that are currently underfunded. For the purposes of platform support it may be easier to pay an LLVM developer to write LLVM backends for specific CPU architectures than to write a new rustc backend.
I’m quite happy about alternate compilers cropping up.
I think one thing that will cause trouble is that currently the language is pretty complex, but unspecced. Furthermore, certain things get changed often – Rust is not very forward compatible. By this I mean that the language evolves rapidly, and certain “implementation details” like inference change every now and then too. While this is all backwards compatible, these changes may make more things compile, which you’ll have to notice and add to the GCC backend. This can be tracked by following the RFCs, but many such changes are not RFCd (e.g. a tweak to make inference better).
This won’t be a blocker, but it will be a challenge. I imagine as the GCC frontend matures we’ll get better about communicating such changes and involving GCC folks in decisions.
I’m not sure if you were referring to financial support or general tech/community support. I don’t know anything about the financial side, but I expect the Rust community and teams to be quite positive about this; and we can probably change our processes a bit to make it easier for you (e.g. by being more careful about noting forwards-incompatible changes).
The way i see it there are 2 main options after reviewing some code today:
Start the compiler front-end within GCC and have an alternate compiler from scratch. Same approach as gcc-go. Have some license clause to allow for the reuse of the rust standard library. This would be the best approach if the language is stable i found: https://github.com/rust-lang/rust/tree/master/src/grammar could be reused to bootstrap the front-end to get working on the dataflow-analysis etc.
Reuse libgccgit David Malcom from Redhat put alot of work getting a cool jit interface into GCC. This could be reused within the Rust code base as an alternate backend. I worry about performance+optimizations problems with this. Never mind deployment and reusablility given users would require libgccgit means we can’t compiler with “-nostdlib -nostdinc -fno-builtin -nostartfiles -nodefaultlibs” which would just suck. But then its the easiest approach.
I was pointed at this thread; I’m the author and maintainer of libgccjit.
Although it has “jit” in the name, libgccjit can be thought of as a library for accessing gcc’s backend, and so it can be used for ahead-of-time compilation (as well as the JIT use-case). See e.g.: https://gcc.gnu.org/onlinedocs/jit/intro/tutorial05.html
which implements a Brainf**k to a.out compiler using libgccjit (including debugger support!)
My hope is that rustc could use libgccjit as a code-generation backend. There are already Rust bindings for libgccjit; see:
That said, I’m a relative novice at Rust, and I don’t know how deeply integrated LLVM is into rustc’s code (I’m also busy, working full-time on gcc 8 upstream; I can spare cycles to help someone who wants to hack on this, but I can’t be primary author/maintainer).
@redbrain: I’m not sure what you mean by the sentence about “-nostdlib -nostdinc -fno-builtin -nostartfiles -nodefaultlibs”. Can you clarify please?
The tough thing here is that the standard library uses unstable language features itself. So an independent Rust front-end can’t limit itself to the stable language if it wants to reuse std.
Apologies i wasn’t sure if ahead of time compilation was possible. I was thinking some people love to try os development with rust and those are options used in that case i thought if we required to JIT doing that type of work wouldn’t be possible. But I stand corrected this is looking to be the best solution now and a good use case of your work! Thanks
(I’ve been thinking about this topic “Rust support in GCC” for a few months, but have never been able to dedicate a big-enough amount of time to it…)
As long as the Rust programming language is not properly specified, I suppose writing a new front end is too big of a task: that basically means having to chase upstream Rust changes continuously. (That is, unless such an effort were absolutely backed by the current Rust stakeholders, on all relevant levels: developers, language maintainers, management.) So, to me, as a pragmatic engineer, re-using the existing Rust front end is the only feasible option right now, to add “Rust support in GCC”.
@dmalcolm’s libgccjit has been suggested, and I can additionally/alternatively see the following option: the current Rust front end certainly must be generating some intermediate language (pure LLVM IR, or some variant thereof?). Assuming this IL is reasonably stable, we could write a GCC front end for that instead of a front end for the evolving Rust programming language. (In a way, similar to the BRIG/HSAIL front end that has recently been contributed to GCC, for example.)
Such a GCC front end for LLVM IR might have appeal in its own right – alternatively, some might find it disgusting – for there are also other languages nowadays that are not supported in GCC but for which LLVM-based front ends exist.
(I have not yet looked into any potential licensing issues, but I don’t really expect any, if interoperating at the IL level.)
Unfortunately, it’s unlikely that I’ll be able to dedicate a major amount of time to such a task. :-/
I can additionally/alternatively see the following option: the current Rust front end certainly must be generating some intermediate language (pure LLVM IR, or some variant thereof?)
It uses MIR. So yes, maybe making a gcc front-end that compiles mir may be a more feasible approach.
I have not yet been able to spend a lot of time on this, but:
From the little I have read so far, I understand that MIR is an “implementation detail” of the Rust front end, where at the MIR level, important Rust semantic checks are being done, and eventually MIR is translated into (pure?) LLVM IR. So, while eventually it may make sense to have the “GCC back end” consume MIR, for the time being, I suggest(ed) we instead look into creating a LLVM IR front end for GCC: MIR being in flux, unspecified vs. LLVM IR being stable, specified. I’m currently working on that, but slowly, without being able to dedicate a lot of time to that.
Thanks
– for there are also other languages nowadays that are not supported in GCC but for which LLVM-based front ends exist.