Rust Front-End to GCC


#6

This project seems pretty cool!

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


#7

The way i see it there are 2 main options after reviewing some code today:

  1. 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.

  2. 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.


#8

[URL=https://github.com/thepowersgang/mrustc]Would mrustc be a good starting point for that?[/URL]


#9

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?

Hope this is constructive
Dave


#10

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.


#11

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! :smiley: Thanks


#12

(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 :wink: – 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. :-/


#13

I guess that’s sort of the reverse of DragonEgg. (but that project is basically abandoned)


#14

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.


#16

Thanks for the infos! =)

What about the state of the MIR, it’s already integrate on mainline or some nightly build?


#17

MIR is already integrated on mainline, and actually released as stable in Rust 1.12, September 2016. So that was nearly a year ago.


#18

Which begs the question… is there a specification of MIR people can rely on to build a GCC frontend?


#19

There isn’t.


#20

Thanks. I have started a new thread on this.


#21

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.


#22

LLVM IR is not significantly more stable than MIR. It changes in backwards-incompatible ways with every LLVM release (which is admittedly rarer than rustc releases, but if you were to take a snapshot of LLVM trunk every six weeks, you’d also see incompatible changes in almost every release). There’s the ability to auto-upgrade old bitcode files (from several releases back, but not forever), but that only helps you if you use the LLVM libraries, which also don’t have a stable interface.


#23

Has there even been any backwards-incompatible changes in rust in the last few releases?


#24

There are tons of incompatible changes in unstable parts of the language, libraries and compiler in pretty much every release. MIR being the one most relevant to this thread. What is indeed rare (but not ruled out, because bug fixes are exempt) are backwards-incompatible changes in the stable parts of the language, standard library, and compiler interface (CLI flags etc.).


#25

I actually intended to ask if there was any of these changes in MIR, but I accidentally a few words it seems. Though, presumably some unstable functions may end up in MIR even when compiling stable rust so that may be a challenge even if the syntax doesn’t change. (Granted the same would be true for LLVM-IR.)


#26

Well, here’s one happening right now: https://github.com/rust-lang/rust/pull/46142