[HN Gopher] Rust GCC back end was officially accepted into the c...
___________________________________________________________________
Rust GCC back end was officially accepted into the compiler
Author : pjmlp
Score : 113 points
Date : 2021-07-08 17:52 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| chubs wrote:
| Does this mean that all of a sudden you can use Rust for embedded
| devices (such as the hobbyist ESP8266/32) that only ship with a
| GCC toolchain? Neat!
| nynx wrote:
| You can actually already do this. There's a fork of rust that
| uses the xtensa fork of LLVM.
| geofft wrote:
| As background, this is a separate effort from the "GCC Rust"
| project.
|
| This project is using libgccjit, which is basically a library
| interface to GCC (intended for JITs, but here being used for
| ahead-of-time compilation), as an alternative to LLVM for the
| standard Rust compiler ("rustc" aka https://github.com/rust-
| lang/rust). This allows reusing all the logic inside the Rust
| compiler for compiling code, checking types and lifetimes, etc.
| while targeting platforms that LLVM does not support.
|
| The GCC Rust project https://rust-gcc.github.io/ is an
| alternative implementation of Rust inside the GCC project, in
| much the same way that, say, gccgo is an alternative
| implementation of Go or GCJ is an alternative implementation of
| Java. It's adding a Rust frontend to GCC, instead of adding a GCC
| backend to rustc.
|
| From a pure functionality standpoint, the libgccjit approach is
| preferable, because as soon as a feature is in rustc, it's
| usable. You share the same implementation.
|
| Personally, I'm very happy to see it approved because it
| _immediately_ solves a difficult issue with getting Rust into the
| Linux kernel - that the Linux kernel supports many more
| architectures than LLVM does, and rustc doesn 't even support all
| of those (https://github.com/fishinabarrel/linux-kernel-module-
| rust/is... is where things were last time I looked in detail),
| and without _some_ answer for how to get things to compile on
| every architecture, Rust kernel code will have to be limited to
| drivers that are only used on architectures that Rust supports.
|
| From an avoiding-monoculture standpoint, GCC Rust is preferable
| specifically because it's an alternative implementation. I think
| it will be good, long-term, to have that as an option too.
|
| Also, as I understand it, a reason that the company behind
| grsecurity is sponsoring GCC Rust is that they have various GCC
| compiler plugins for hardening, and those would apply
| straightforwardly to GCC Rust, but they wouldn't necessarily
| apply to libgccjit. From
| https://opensrcsec.com/open_source_security_announces_rust_g... :
|
| > _As the source of the GCC plugin infrastructure in the Linux
| kernel and nearly all of the GCC plugins adapted for inclusion in
| the upstream Linux kernel, we too immediately spotted the
| importance of this problem and set out to ensure both those
| plugins as well as the security features built-in to GCC itself
| are able to instrument code from all languages supported by the
| Linux kernel with compatible and consistent security properties._
| nynx wrote:
| I disagree that multiple _frontend_ implementations is going to
| be a good thing for Rust. Multiple backends is great, but
| multiple frontends could result in Rust getting held back to
| the lowest common denominator. C and C++ have multiple
| frontends because of proprietary nonsense. Rust doesn't have
| that problem.
| stu2b50 wrote:
| As long as the current rustc front end is the canonical one I
| think it'll end up fine. As the parent post explains, there
| are niches that want the gcc frontend and they should be able
| to get it.
| apendleton wrote:
| FWIW, an alternative outcome to lowest-common-denominator is
| what's happened with, for example, alternative Python
| implementations: there's still a main blessed one, most
| library authors don't care about whether or not anything
| works on any of the others, and users who want to avail
| themselves of the benefits of one of the alternatives (e.g.,
| better runtime performance on PyPy) probably just can't, if
| the libraries they need aren't supported, unless they go to
| the effort of adding support themselves.
|
| (This outcome is probably also bad, to be clear, but maybe of
| less practical consequence to people who continue to use
| mainline rustc.)
| nynx wrote:
| Yeah, that outcome is still pretty bad. I don't think
| there's any value gained from multiple frontends here. It's
| unlike the PyPy situation in that a Rust GCC frontend is
| not going to have better performance, at least at runtime,
| from rustc with a GCC backend. Any compile performance
| differences could be resolved.
| chrismorgan wrote:
| Multiple implementations _allows_ for competition by novel
| approaches. (It doesn't guarantee that that's the way it'll
| work out, but it makes it _possible_.)
|
| Look at browsers: IE stagnated, Firefox got things going
| again, _and IE eventually improved_. And then as Firefox had
| become bloated, Chrome came along and showed that better
| performance was possible, _and so Firefox improved_ as effort
| to match Chrome was exerted.
|
| Or npm: it got mired as people couldn't agree on the way to
| resolve some pretty big issues (centring on performance), so
| some people started Yarn, and its success helped unstick npm,
| so that now many that had switched to Yarn were able to move
| back to npm once it caught up again.
|
| And these are just a couple of examples I'm familiar with.
|
| Yes, there are costs to diversity of implementation, but
| there are benefits. The reasons why multiple backends is
| great _can_ largely apply to multiple frontends.
|
| Rust's backend and frontend are both performance bottlenecks.
| One perfectly plausible course of events is that someone
| builds a new Rust compiler focused on end-to-end performance.
| That could help both the ecosystem and rustc.
| Dylan16807 wrote:
| I don't really want significant competition _inside_ a
| programming language.
|
| Most features can be added on to an experimental version of
| the existing code base, or done as a prototype. Not much
| needs a full competing compiler.
| geofft wrote:
| As a counterargument, the web platform has multiple
| "frontends" (multiple, unrelated codebases that interpret
| HTML and JS and CSS, not just multiple engines/renderers),
| and the argument to avoid the monoculture seems good there.
|
| Although, hm, I suppose you could argue that if there were
| one libhtml5 and Gecko and Blink and WebKit all used that,
| but they had different "backends," that might be even better
| than the current situation - that the value of having
| multiple web browsers is in the equivalent to the backends,
| not in the equivalent to the frontends.
| kzrdude wrote:
| GCC vs llvm competition has been beneficial for C++, though
| nynx wrote:
| And it's going to be beneficial for Rust too. Just there's
| no reason to have multiple frontends.
| cmrdporcupine wrote:
| This is new, though. Back in the 90s and early 2000s the
| compiler situation for C++ held back the language because
| the intersection of features from the "standard" available
| through both MSCV and GCC wasn't ideal. Both were good
| compilers. But in different ways.
|
| Nowadays it's pretty trivial to get a codebase to compile
| across MSVC, GCC and Clang. Back then it was often weeks
| and weeks of work.
| brundolf wrote:
| This sounds like a social issue though (compiler teams
| cooperating and keeping things up to date). It seems like
| when you have a smaller number of implementations they
| tend to be more agile; look at the modern web browser
| landscape vs that of the 2000s, for example
|
| I'd bet that having exactly two implementations will be a
| good place to be
| cmrdporcupine wrote:
| Yes, it was definitely social at least in part because MS
| leadership at that time didn't see something like GCC as
| a legitimate partner to cooperate with. They wanted open
| source to go away. Things definitely changed in that
| regard later.
|
| I think you're probably right that two Rust
| implementations with a cooperative mentality would be a
| good thing in the long run.
| cbmuser wrote:
| Yes, but it has not been merged yet. At least, I'm not seeing it
| in the "compiler" directory.
| est31 wrote:
| The MCP has been accepted, which is a way to gain consensus in
| the Rust compiler team to do some implementation work. The PR
| will follow.
___________________________________________________________________
(page generated 2021-07-08 23:02 UTC)