Live data from Hacker News

A possible new back end for Rust

jason-williams.co.uk

11–20 of 224 posts

Re: A possible new back end for Rust

#11

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/

Re: A possible new back end for Rust

#12
post #7

While it appears that cg_clif is faster to compile, does it provide any performance benefit compared to cg_llvm? Are the compiled binaries as fast as llvm compiled binaries? If not is the use-case for development purposes only?

From the article, it is pretty clear that the resulting code is not as optimized as the LLVM backend. I didn't see any claims of how much slower it would be, but clearly that will vary greatly. Fast to compile is still really handy while developing.

Re: A possible new back end for Rust

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

The semantics of C aren't very well defined, there is a lot of ambiguity in the form of undefined and implementation defined behaviour. This ambiguity is often needed to build an efficient optimizing compiler. When you have a higher level language with more accurately defined semantics, running it all through C would risk introducing undefined behaviour. With an IR you can control and define the semantics more closel…

I've got to wonder if any of the existing intermediate representations would be appropriate with other programming languages.

Re: A possible new back end for Rust

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

While a C backend is great for compatibility, is it a sufficient IL to express everything? For example, Rust has some extra guarantees with aliasing that I'm unsure if C or C extensions support yet that could offer greater optimizations (currently not fully being used due to bugs in the LLVM backend).

Re: A possible new back end for Rust

#15

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…

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

Re: A possible new back end for Rust

#16
This feels welcome to me. I tend to think a language needs multiple independent implementations that only share the same source language spec, in order to really tear a clear spec apart from the quirks of any particular implementation.

I find Rust (the spec, though also the implemenration) quite safe and practical (a balance). It deserves some independent implementations to secure a long and stable future.

On the other hand, I want to use it on non-ARM embedded platforms, where current cross-compilation through C produces unusably big binaries. I dream this might increase hope for that, too, eventually.

Re: A possible new back end for Rust

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

Modern compilers generally have a language-specific front and that generates an intermediate representation of the program logic, which is then transformed into an abstract representation (such as a single static analysis tree) for optimization. That is then transformed into an abstract machine description language, which gets further transformed by the back end into concrete machine instructions or assembly code.

Outside of the language-specific front end, compilers generally have no knowledge of the programming language itself. There is no technical advantage to transforming Rust into C when it comes to the middle and back ends, which form the bulk of the compiler.

There are no language-specific optimization opportunities. There are, of course, restrictions on what you can do in some languages that eliminate optimization opportunities, but you're not suddenly going to be able to take advantage of those opportunities by transforming your code into a langue that lacks the restrictions, because then you change the semantics of your code.

Re: A possible new back end for Rust

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

It's a sad thing that you've been downvoted for posting a thought. Others have already said the drawbacks of this idea, but there are also pros.

Re: A possible new back end for Rust

#19

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…

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

Re: A possible new back end for Rust

#20
post #16

This feels welcome to me. I tend to think a language needs multiple independent implementations that only share the same source language spec, in order to really tear a clear spec apart from the quirks of any particular implementation. I find Rust (the spec, though also the implemenration) quite safe and practical (a balance). It deserves some independent implementations to secure a long and stable future. On the oth…

>> I find Rust (the spec, though also the implemenration) quite safe and practical (a balance). It deserves some independent implementations to secure a long and stable future.

Where is the Rust spec? Unless something happened really quickly that I was not aware of there is only the implementation.

Post reply on HN