13 ms·

Rustc_codegen_GCC can now bootstrap rustc

197 points by bestouff 5y ago

VWWHFSfQ 5y ago
This is all very exciting. I'm guessing we'll see some pretty major performance improvements for rust code in addition to all the new supported architectures
- roblabla 5y ago
  I don't see why the GCC codegen would end up with major performance improvements - my understanding is that GCC and LLVM are basically on par with performance, with some workloads being a tiny bit better in one or the other. Is that wrong?
  - bumblebritches5 5y ago
  - mhh__ 5y ago
    GCC is still basically better overall but it's basically chaotic. LLVM seems to have better defaults for branch-y compiler code, but GCC has a lot of tricks up its sleeve that LLVM hasn't got. FWIW though I think GCC is really playing with fire when it comes to it's future - the mailing list approach to development deters new contributors, the testing infrastructure is quite arcane, etc. GCC should be an aspirational tool that people want to contribute to but aside from a few core contributors it feels like its basically on life support in some regards. And I say that as someone who actively tries to use it. Its core competencies are pretty good but it's (mostly stallman, to be blunt) legacy has made it very brittle at its extremities e.g. LTO explodes on me way too often.
    - mahkoh 5y ago
      >FWIW though I think GCC is really playing with fire when it comes to it's future - the mailing list approach to development deters new contributors, the testing infrastructure is quite arcane, etc. And LLVM is better? At the start of last year I found and fixed a small bug in LLVM[1]. I submitted the fix via their Phabricator instance and it was approved by project members after a few days. As per the contributor guide, I then asked for a project member to commit my patch to the LLVM repository. This is because in Phabricator there does not appear to be an automatic way to commit approved changes. A project member has to manually take the patch and apply it. A few weeks ago I tried to see what happened to my patch and found that it had never been applied. So basically my work and that of the reviewers was simply lost because of their infrastructure. [1] https://reviews.llvm.org/D96334 https://reviews.llvm.org/D96334
      - stjohnswarts 5y ago
        Did you try again? I'm not discounting your efforts but n=1 is not an optimal way to determine that LLVM change/bugfix process is "broken".
      - jmorse2 5y ago
        (NB: the developers guide says to ping if there's no activity for a week)
      - mhh__ 5y ago
        I get that LLVM can be bad too but at least there's a phabricator at all.
  - ______-_-______ 5y ago
    Up until now the rust compiler has been finely tuned for LLVM. I would expect the GCC backend to perform worse initially, then improve over time depending on how much use it gets.
    - mhh__ 5y ago
      There isn't actually that much that a frontend author can do to tune it beyond exposing the right invariants.
goombacloud 5y ago
It's really great to be able to skip compiling LLVM when bootstrapping a whole OS/toolchain from source and only Rust happens to pull LLVM in. Besides the gcc work I'm actually also hoping for the rustc_codegen_cranelift work to land one day!
- Vogtinator 5y ago
  For proper bootstrapping I'm looking forward to gccrs (https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs) alongside mrustc.
- hardware2win 5y ago
  Compiling llvm is a nightmare
  - wyldfire 5y ago
    In terms of satisfying the dependencies, or the build time, or something else?
    - JonChesterfield 5y ago
      Dependencies are few and largely optional but build time is tedious
    - aseipp 5y ago
      Build time. If you only need one or two components (clang, clang-tools-extra) and trim down the number of target architectures, it's not so bad. But if you want most of the components and architectures enabled, and tested with a Release-with-asserts build... The build parallelism scales pretty well though so if you want some white noise in the background, by all means. It's kind of nice for keeping your feet warm sometimes.
  - da-x 5y ago
    Compiling LLVM for what purpose? Hacking on it? Producing an optimized build? Installing a build on a user's machine? You should be more specific. The default clean build works just fine. On my machine I can clone the Git repo, do `mkdir build && cmake ../llvm && make -j64` and end up with working binaries after 5 minutes. The build take 37GB by default here, and the binaries under bin/ are immediately usable work. If you want a smaller build with shared library just add a parameter. Want to throw in sub-projects such as LLD or Clang? Just another parameter. It's all very well-documented.
chakkepolja 5y ago
PS: For any students here, GSoC 2022 has some projects on GCC Rust frontend: https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas

197 points by bestouff 5y ago

This is all very exciting. I'm guessing we'll see some pretty major performance improvements for rust code in addition to all the new supported architectures

roblabla 5y ago
I don't see why the GCC codegen would end up with major performance improvements - my understanding is that GCC and LLVM are basically on par with performance, with some workloads being a tiny bit better in one or the other. Is that wrong?
- bumblebritches5 5y ago
- mhh__ 5y ago
  GCC is still basically better overall but it's basically chaotic. LLVM seems to have better defaults for branch-y compiler code, but GCC has a lot of tricks up its sleeve that LLVM hasn't got. FWIW though I think GCC is really playing with fire when it comes to it's future - the mailing list approach to development deters new contributors, the testing infrastructure is quite arcane, etc. GCC should be an aspirational tool that people want to contribute to but aside from a few core contributors it feels like its basically on life support in some regards. And I say that as someone who actively tries to use it. Its core competencies are pretty good but it's (mostly stallman, to be blunt) legacy has made it very brittle at its extremities e.g. LTO explodes on me way too often.
  - mahkoh 5y ago
    >FWIW though I think GCC is really playing with fire when it comes to it's future - the mailing list approach to development deters new contributors, the testing infrastructure is quite arcane, etc. And LLVM is better? At the start of last year I found and fixed a small bug in LLVM[1]. I submitted the fix via their Phabricator instance and it was approved by project members after a few days. As per the contributor guide, I then asked for a project member to commit my patch to the LLVM repository. This is because in Phabricator there does not appear to be an automatic way to commit approved changes. A project member has to manually take the patch and apply it. A few weeks ago I tried to see what happened to my patch and found that it had never been applied. So basically my work and that of the reviewers was simply lost because of their infrastructure. [1] https://reviews.llvm.org/D96334 https://reviews.llvm.org/D96334
    - stjohnswarts 5y ago
      Did you try again? I'm not discounting your efforts but n=1 is not an optimal way to determine that LLVM change/bugfix process is "broken".
    - jmorse2 5y ago
      (NB: the developers guide says to ping if there's no activity for a week)
    - mhh__ 5y ago
      I get that LLVM can be bad too but at least there's a phabricator at all.
- ______-_-______ 5y ago
  Up until now the rust compiler has been finely tuned for LLVM. I would expect the GCC backend to perform worse initially, then improve over time depending on how much use it gets.
  - mhh__ 5y ago
    There isn't actually that much that a frontend author can do to tune it beyond exposing the right invariants.

goombacloud 5y ago

It's really great to be able to skip compiling LLVM when bootstrapping a whole OS/toolchain from source and only Rust happens to pull LLVM in. Besides the gcc work I'm actually also hoping for the rustc_codegen_cranelift work to land one day!

Vogtinator 5y ago
For proper bootstrapping I'm looking forward to gccrs (https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs) alongside mrustc.
hardware2win 5y ago
Compiling llvm is a nightmare
- wyldfire 5y ago
  In terms of satisfying the dependencies, or the build time, or something else?
  - JonChesterfield 5y ago
    Dependencies are few and largely optional but build time is tedious
  - aseipp 5y ago
    Build time. If you only need one or two components (clang, clang-tools-extra) and trim down the number of target architectures, it's not so bad. But if you want most of the components and architectures enabled, and tested with a Release-with-asserts build... The build parallelism scales pretty well though so if you want some white noise in the background, by all means. It's kind of nice for keeping your feet warm sometimes.
- da-x 5y ago
  Compiling LLVM for what purpose? Hacking on it? Producing an optimized build? Installing a build on a user's machine? You should be more specific. The default clean build works just fine. On my machine I can clone the Git repo, do `mkdir build && cmake ../llvm && make -j64` and end up with working binaries after 5 minutes. The build take 37GB by default here, and the binaries under bin/ are immediately usable work. If you want a smaller build with shared library just add a parameter. Want to throw in sub-projects such as LLD or Clang? Just another parameter. It's all very well-documented.

chakkepolja 5y ago

PS: For any students here, GSoC 2022 has some projects on GCC Rust frontend: https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas