3 ms·

Why would anyone bother with GCC then? :P

by codeshaunted 1y ago

bombcar 1y ago
I believe GCC still wins by far on support for weird CPUs and embedded systems.
- codeshaunted 1y ago
  With LLVM I doubt this will remain true. LLVM makes custom code generation far too easy for GCC to remain viable imo.
  - jcranmer 1y ago
    I don't have much experience with writing a custom gcc backend, but my experience with LLVM is that its model ends up being a somewhat poor fit for smaller or weirder architectures. For example, LLVM has this annoying tendency to really aggressively promote the size of everything--if you have a 32-bit core with 64-bit memory indexing, LLVM tends to make anything that eventually becomes a memory index a 64-bit computation, even if it would be more efficient to keep everything as 32-bit.
  - mort96 1y ago
    Hm, is it so much easier to write an LLVM back-end than a GCC back-end? I haven't looked into GCC's code gen infrastructure that much, but I looked into making a new back-end to LLVM some time ago and it seemed extremely complex and entirely undocumented. All guidance I found on it basically amounted to, "copy an existing back-end and bang it against a rock until you've made it generate the machine code you need". And it certainly wasn't a case of having clean and simple enough code to make documentation unnecessary. It would honestly surprise me if GCC is more difficult to add a back-end to.
  - SubjectToChange 1y ago
    The problem is that "weird CPUs and embedded systems" are not mainstream platforms, nor do they have a lot of money behind them (particularly for open source development). Hence, there is little motivation and/or resources for anyone to develop a new backend for LLVM when a mature GCC backend already exists. Moreover, the LLVM developers are weary to accept new backends for niche platforms when there is no guarantee that they will be maintained in the future.
    - bombcar 1y ago
      Exactly - often the GCC branch is barely maintained by whoever is selling the CPU/chip, and it is patches against a specific version that you must use, or it goes haywire. At least with GCC they can sometimes merge the patches.
- bobmcnamara 1y ago
  It's still a crapshoot. GCC on xtensa adds extra instructions in several places. GCC on Arm Cortex-M0 has awful register allocation, and M0 has half as many registers as most ARMs...
SubjectToChange 1y ago
GCC still for Linux distributions using glibc or any other library with many "GCCisms". Also, I'm not sure whether or not Clang is ABI compatible enough for enterprise customers with some rather extreme backwards compatibility requirements. Still, I can imagine a future where glibc can be built with Clang, possibly even one where llvm-libc is "good enough" for many users.
IshKebab 1y ago
Mainly because it was the default for so long, and Clang isn't so much better that distros really need to switch.
jart 1y ago
GCC is still marginally superior at both code size and performance in my experience. The main thing I like about clang is it compiles byzantine c++ code much faster. Some projects like llama.cpp it's like eating nails if you're not using clang. So with projects like llamafile I usually end up using both compilers. That's why my cosmocc toolchain comes with -mgcc and -mclang.

Why would anyone bother with GCC then? :P

bombcar 1y ago

I believe GCC still wins by far on support for weird CPUs and embedded systems.

codeshaunted 1y ago
With LLVM I doubt this will remain true. LLVM makes custom code generation far too easy for GCC to remain viable imo.
- jcranmer 1y ago
  I don't have much experience with writing a custom gcc backend, but my experience with LLVM is that its model ends up being a somewhat poor fit for smaller or weirder architectures. For example, LLVM has this annoying tendency to really aggressively promote the size of everything--if you have a 32-bit core with 64-bit memory indexing, LLVM tends to make anything that eventually becomes a memory index a 64-bit computation, even if it would be more efficient to keep everything as 32-bit.
- mort96 1y ago
  Hm, is it so much easier to write an LLVM back-end than a GCC back-end? I haven't looked into GCC's code gen infrastructure that much, but I looked into making a new back-end to LLVM some time ago and it seemed extremely complex and entirely undocumented. All guidance I found on it basically amounted to, "copy an existing back-end and bang it against a rock until you've made it generate the machine code you need". And it certainly wasn't a case of having clean and simple enough code to make documentation unnecessary. It would honestly surprise me if GCC is more difficult to add a back-end to.
- SubjectToChange 1y ago
  The problem is that "weird CPUs and embedded systems" are not mainstream platforms, nor do they have a lot of money behind them (particularly for open source development). Hence, there is little motivation and/or resources for anyone to develop a new backend for LLVM when a mature GCC backend already exists. Moreover, the LLVM developers are weary to accept new backends for niche platforms when there is no guarantee that they will be maintained in the future.
  - bombcar 1y ago
    Exactly - often the GCC branch is barely maintained by whoever is selling the CPU/chip, and it is patches against a specific version that you must use, or it goes haywire. At least with GCC they can sometimes merge the patches.
bobmcnamara 1y ago
It's still a crapshoot. GCC on xtensa adds extra instructions in several places. GCC on Arm Cortex-M0 has awful register allocation, and M0 has half as many registers as most ARMs...

SubjectToChange 1y ago

GCC still for Linux distributions using glibc or any other library with many "GCCisms". Also, I'm not sure whether or not Clang is ABI compatible enough for enterprise customers with some rather extreme backwards compatibility requirements. Still, I can imagine a future where glibc can be built with Clang, possibly even one where llvm-libc is "good enough" for many users.

IshKebab 1y ago

Mainly because it was the default for so long, and Clang isn't so much better that distros really need to switch.

jart 1y ago

GCC is still marginally superior at both code size and performance in my experience. The main thing I like about clang is it compiles byzantine c++ code much faster. Some projects like llama.cpp it's like eating nails if you're not using clang. So with projects like llamafile I usually end up using both compilers. That's why my cosmocc toolchain comes with -mgcc and -mclang.