Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A possible new back end for Rust

jason-williams.co.uk

Post reply on HN
Print view View original

31–40 of 224 posts

Re: A possible new back end for Rust

#31

Post by Rochus »

pizlonator wrote: post #2

This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm. I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t b…

Now it's called monoculture? Rather strange. But anyway: in your terms you're just replacing LLVM monoculture by Rust monoculture, isn't it?

Re: A possible new back end for Rust

#33

Post by bluejekyll »

edwintorok wrote: post #11
pizlonator wrote: post #2

This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm. I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t b…

Worth mentioning other alternative small backends: http://c9x.me/compile/

While the GP doesn’t state this as an advantage, the Rust community would benefit from a fully Rust toolchain.

Re: A possible new back end for Rust

#34

Post by bluGill »

bluejekyll wrote: post #33
edwintorok wrote: post #11

Earlier quoted context omitted.

Worth mentioning other alternative small backends: http://c9x.me/compile/

While the GP doesn’t state this as an advantage, the Rust community would benefit from a fully Rust toolchain.

Why? Other than to prove it can be done what is the point.

If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources.

There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe they will split resources that could be used to make something else better.

Re: A possible new back end for Rust

#35

Post by hawski »

ddevault wrote: post #30
edwintorok wrote: post #11

Earlier quoted context omitted.

Worth mentioning other alternative small backends: http://c9x.me/compile/

I use qbe, it's great. Here's a mostly feature-complete C11 compiler based on qbe: https://git.sr.ht/~mcf/cproc

I see that cproc is under quite heavy development, but qbe had last commit at the end of November. Is it considered feature complete? I heard about it some months ago and was quite interested in QBE, but it did not enjoy high tempo of changes. It may be considered advantage, I know too little to judge.

Re: A possible new back end for Rust

#36

Post by stephencanon »

Koshkin wrote: post #5

I've been wondering lately if the modern compilers should all be using C as the intermediate language (or some language-specific code optimization opportunities could be lost if they do that).

If you're trying to implement a language with substantially different semantics from C (e.g. a substantially different memory model, or without UB) the semantics of C make it really unsuitable as an IR.

You can't use C's casts (undef for out of range float -> int conversions, for example), arithmetic (undef for signed overflow), or shift operators (implementation-defined behavior for signed right shifts, undefined behavior for left shifts into the signbit or shift counts not in [0, n)). You can work around these by defining functions with the semantics that your language needs, but they get gross pretty quickly (they are both much more verbose and more error-prone than having an IR with the semantics you really want, and they require optimizer heroics to reassemble them into the instructions you really want to generate). Alternatively, you can use intrinsics or compiler builtins, but then you're effectively locking yourself to a single backed anyway, and might as well use its IR.

The issues around memory models (especially aliasing, but also support for unaligned access, dynamic layouts, etc) are worse.

Even LLVM IR is too tightly coupled to the semantics of C and C++ to be easily usable as a really generic IR for arbitrary languages (Rust, Swift, and the new Fortran front end have all had some struggles with this, and they're more C-like than most languages). C is much worse in this regard.

Re: A possible new back end for Rust

#37

Post by ddevault »

hawski wrote: post #35
ddevault wrote: post #30

Earlier quoted context omitted.

I use qbe, it's great. Here's a mostly feature-complete C11 compiler based on qbe: https://git.sr.ht/~mcf/cproc

I see that cproc is under quite heavy development, but qbe had last commit at the end of November. Is it considered feature complete? I heard about it some months ago and was quite interested in QBE, but it did not enjoy high tempo of changes. It may be considered advantage, I know too little to judge.

It's complete enough to compile C11 programs - to me, that's as good of a benchmark as anything. The main thing qbe is missing for cproc's purposes is inline assembly and VLAs. DWARF support would also be nice, but no one seems to care enough to do the work yet.

Re: A possible new back end for Rust

#38

Post by gok »

Novel compiler backends are a super cool idea, but I don't think it's going to help Rust compile speeds as much as this posts suggests. The complexity of Rust's type system puts a pretty high lower bound on compile times because of work the front end needs to do. Plain C compiles quickly even with an LLVM backend, for example.

Re: A possible new back end for Rust

#39

Post by CJefferson »

ddavis wrote: post #19
VHRanger wrote: post #15

Earlier quoted context omitted.

Note that the LLVM monoculture came about because of how much of a pain GCC is to work with. And GCC being a pain to work with is a deliberate decision by Stallman to avoid his baby being expanded upon by corporations

It's unfair to rms to say that. He would be happy for corporations to use and contribute to any project associated with the GNU project (like GCC), if everyone wanted to play along in GPL land (which of course isn't reality).

Unfortunately not. For years people wanted gcc to output a nice parse tree for C++, which would have been plenty useful for open source text editors, but was banned by RMS as it would also be useful for closed source systems.

Re: A possible new back end for Rust

#40

Post by sambe »

bluGill wrote: post #34
bluejekyll wrote: post #33

Earlier quoted context omitted.

While the GP doesn’t state this as an advantage, the Rust community would benefit from a fully Rust toolchain.

Why? Other than to prove it can be done what is the point. If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources. There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe the…

Why phrase it as "other than to prove it can be done" if you already know there are good answers? I think the following obviously do apply:

1) much easier for Rust community to contribute to the compiler from end-to-end.

2) lower coordination cost with LLVM giving complete, Rust-focussed control over code generation/optimisation. Think about e.g. fixing noalias.

3) lower maintenance cost for LLVM integration/fork.

It's also obvious that this needs to be weighed against the loss of LLVM accumulated technology and contributors. This is easy to underestimate (although I think 2)/3) are also easy to underestimate).

Post reply on HN