A possible new back end for Rust • Hacker News Board

Re: A possible new back end for Rust

#21

Post by jfkebwjsbx » Tue, Apr 21, 2020, 2:39 PM UTC

bregma wrote: post #17

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

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. Ou…

> There is no technical advantage to transforming Rust into C

There is a key one: the ability to use any C compiler out there (including proprietary ones). This allows you to target all platforms out there.

Re: A possible new back end for Rust

#22

Post by steveklabnik » Tue, Apr 21, 2020, 2:42 PM UTC

thesuperbigfrog wrote: post #20

korpiq wrote: 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.

https://doc.rust-lang.org/stable/reference/ is the closest thing we have. It is not yet complete.

Re: A possible new back end for Rust

#23

Post by jfkebwjsbx » Tue, Apr 21, 2020, 2:44 PM UTC

edwintorok wrote: post #8

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

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…

> When you have a higher level language with more accurately defined semantics, running it all through C would risk introducing undefined behaviour.

No, it wouldn't. When you target C you need to write a proper backend for its abstract machine, rather than naively rewriting code, of course.

The C abstract machine is a fine IR, specially the later editions of the standard.

Re: A possible new back end for Rust

#24

Post by thesuperbigfrog » Tue, Apr 21, 2020, 2:44 PM UTC

steveklabnik wrote: post #22

thesuperbigfrog wrote: post #20

Earlier quoted context omitted.

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

https://doc.rust-lang.org/stable/reference/ is the closest thing we have. It is not yet complete.

Thank you! I look forward to the day when there is a spec, but I was surprised to see it mentioned and was wondering if I missed something big.

Re: A possible new back end for Rust

#25

Post by steveklabnik » Tue, Apr 21, 2020, 2:45 PM UTC

ansible wrote: post #13

edwintorok wrote: post #8

Earlier quoted context omitted.

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.

This is true to varying degrees, you could say that LLVM-IR and Java bytecode are two examples of this in action.

Re: A possible new back end for Rust

#26

Post by jlebar » Tue, Apr 21, 2020, 2:47 PM UTC

If there are any rust people here, you've probably considered that you can speed up your debug llvm builds by enabling some optimizations. SimplifyCFG comes to mind, but, like, you can experiment. I presume the reason you haven't is because you want to preserve debug info, and llvm isn't great at that when optimizations are on.

Re: A possible new back end for Rust

#27

Post by the8472 » Tue, Apr 21, 2020, 2:50 PM UTC

jlebar wrote: post #26

If there are any rust people here, you've probably considered that you can speed up your debug llvm builds by enabling some optimizations. SimplifyCFG comes to mind, but, like, you can experiment. I presume the reason you haven't is because you want to preserve debug info, and llvm isn't great at that when optimizations are on.

You can customize the debug profile or create an intermediate profile between release and debug in your Cargo.toml. Debug info and optimization levels can be configured separately.

If by speed up you mean compile times and not runtime behavior then there's also some unstable compiler flag that allows adding specific llvm passes.

Re: A possible new back end for Rust

#28

Post by yjftsjthsd-h » Tue, Apr 21, 2020, 2:52 PM UTC

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

I think it's partially fair; gcc, in order to make it impossible to add proprietary add-ons, deliberately has an non-modular architecture, which makes it hard even for open source extensions to exist.

Re: A possible new back end for Rust

#29

Post by Ididntdothis » Tue, Apr 21, 2020, 2:56 PM UTC

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

That’s how C++ started out but as far as I know this had lots of limitations in terms of optimization so they started writing native C++ compilers.

Re: A possible new back end for Rust

#30

Post by ddevault » Tue, Apr 21, 2020, 3:00 PM UTC

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/

I use qbe, it's great. Here's a mostly feature-complete C11 compiler based on qbe:

https://git.sr.ht/~mcf/cproc