4 ms·

Better optimizations? AFAIR, the go compiler does some optimizations, but it does not bend over backwards, exactly. Maybe hooking up to llvm can help with that,

by krylon 9y ago

Better optimizations? AFAIR, the go compiler does some optimizations, but it does not bend over backwards, exactly. Maybe hooking up to llvm can help with that, if it is a goal. (Mmmh, does LLVM optmize at all, or does it just provide a framework for people trying to build optimizing compilers? I don't really know.) Also, llvm by now reaches far more platforms than the current go compiler. I think that this is the most likely explanation.

kibwen 9y ago
But gccgo already exists, and provides an optimizing compiler backend and extended platform support. And the tools in LLVM's ecosystem seem largely useless to Go (no need for asan et al when you have a GC, and no need for tsan when Go already has an optional race detector). Other than the compiler itself having a permissive license, I see no urgent impetus for an LLVM backend for Go, which likely explains why it's taking so long coming.
- pcwalton 9y ago
  LLVM has better support for moving GC, due to Azul's efforts. That's a big difference.
  - kibwen 9y ago
    Doesn't gccgo reuse the standard Go runtime, and wouldn't integrating LLVM'S GC support require pretty much writing a brand-new runtime?
    - pcwalton 9y ago
      LLVM doesn't come with a garbage collector; it comes with hooks you can plug your GC into. So it'd require a good bit of work to integrate with LLVM's GC support, but nowhere near rewriting the whole runtime.
- cyphar 9y ago
  > But gccgo already exists, and provides an optimizing compiler backend and extended platform support. We (SUSE / openSUSE) had an incredible amount of issues with gccgo. The main problem was that the runtime wasn't updated often enough, they had some odd patches that broke the runtime, and you generally had to update the compiler to update the Go version (quite difficult in enterprise distributions).
  - kibwen 9y ago
    Wouldn't you have those same problems with an LLVM-based backend? LLVM moves very quickly, and AFAICT upgrades are non-trivial.
    - cyphar 9y ago
      The problem wasn't the code generation, it's that it was maintained in a way that made it very difficult to update in distributions. They also broke the stdlib in a few versions. But even if you ignore all of that, if it was supported by upstream then we would have more fate in it than using a franken-compiler. ;)

by krylon 9y ago

kibwen 9y ago

But gccgo already exists, and provides an optimizing compiler backend and extended platform support. And the tools in LLVM's ecosystem seem largely useless to Go (no need for asan et al when you have a GC, and no need for tsan when Go already has an optional race detector). Other than the compiler itself having a permissive license, I see no urgent impetus for an LLVM backend for Go, which likely explains why it's taking so long coming.

pcwalton 9y ago
LLVM has better support for moving GC, due to Azul's efforts. That's a big difference.
- kibwen 9y ago
  Doesn't gccgo reuse the standard Go runtime, and wouldn't integrating LLVM'S GC support require pretty much writing a brand-new runtime?
  - pcwalton 9y ago
    LLVM doesn't come with a garbage collector; it comes with hooks you can plug your GC into. So it'd require a good bit of work to integrate with LLVM's GC support, but nowhere near rewriting the whole runtime.
cyphar 9y ago
> But gccgo already exists, and provides an optimizing compiler backend and extended platform support. We (SUSE / openSUSE) had an incredible amount of issues with gccgo. The main problem was that the runtime wasn't updated often enough, they had some odd patches that broke the runtime, and you generally had to update the compiler to update the Go version (quite difficult in enterprise distributions).
- kibwen 9y ago
  Wouldn't you have those same problems with an LLVM-based backend? LLVM moves very quickly, and AFAICT upgrades are non-trivial.
  - cyphar 9y ago
    The problem wasn't the code generation, it's that it was maintained in a way that made it very difficult to update in distributions. They also broke the stdlib in a few versions. But even if you ignore all of that, if it was supported by upstream then we would have more fate in it than using a franken-compiler. ;)