6 ms·

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,

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.

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.