Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gollvm from Google

go.googlesource.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Gollvm from Google

#41

Post by weberc2 »

wyldfire wrote: post #38
weberc2 wrote: post #15

Earlier quoted context omitted.

Go already has its own intermediate representation to solve this problem, so this project must solve some other problem.

Go having its own intermediate representation "solves" the problem but requires go-specific backends/lowering mechanisms. LLVM is arguably a more generic place for backends to live. (though in practice it does serve clang's needs best). If you design a new processor, you generally take it upon yourself to do the work necessary for folks to use C compilers that target your processors. I'd argue that they're more likel…

I don't disagree, but that's a different problem than the one discussed above. :)

Re: Gollvm from Google

#42

Post by weberc2 »

ndesaulniers wrote: post #31
weberc2 wrote: post #15

Earlier quoted context omitted.

Go already has its own intermediate representation to solve this problem, so this project must solve some other problem.

But go ir != llvm ir. The idea is you can leave behind optimizations passes and backend, simply maintaining a frontend, when you adopt the llvm ir and toolchain.

I don't disagree, but this is a different problem than the one cited above.

Re: Gollvm from Google

#43

Post by kibwen »

cyphar wrote: post #39
kibwen wrote: post #17

Earlier quoted context omitted.

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 ta…

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

Wouldn't you have those same problems with an LLVM-based backend? LLVM moves very quickly, and AFAICT upgrades are non-trivial.

Re: Gollvm from Google

#44

Post by kibwen »

pcwalton wrote: post #28
kibwen wrote: post #17

Earlier quoted context omitted.

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 ta…

LLVM has better support for moving GC, due to Azul's efforts. That's a big difference.

Doesn't gccgo reuse the standard Go runtime, and wouldn't integrating LLVM'S GC support require pretty much writing a brand-new runtime?

Re: Gollvm from Google

#45

Post by marmaduke »

theparanoid wrote: post #25
marmaduke wrote: post #2

This means we could write numerical code in Go and get auotvectorized assembly and use GPUs via the nvptx backend. Neat!

Go is a GC language. Only a strict subset would be amenable to running on a GPU.

If you noticed, I did say numerical algorithms, for most of which it's usually easy to allocate memory in advance.

I didn't mean anyone would want to do this but just that it's an interesting parallelism for a language.

Re: Gollvm from Google

#46

Post by pcwalton »

kibwen wrote: post #44
pcwalton wrote: post #28

Earlier quoted context omitted.

LLVM has better support for moving GC, due to Azul's efforts. That's a big difference.

Doesn't gccgo reuse the standard Go runtime, and wouldn't integrating LLVM'S GC support require pretty much writing a brand-new runtime?

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.

Re: Gollvm from Google

#47

Post by cyphar »

kibwen wrote: post #43
cyphar wrote: post #39

Earlier quoted context omitted.

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

Wouldn't you have those same problems with an LLVM-based backend? LLVM moves very quickly, and AFAICT upgrades are non-trivial.

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

Re: Gollvm from Google

#48

Post by jen20 »

pm90 wrote: post #5

So question for llvm devs here: what benefit does this provide? How does it enhance go? Does it make go programs compile into more efficient binaries targeted to specific cpu architectures?

Hopefully following the system ABI on AMD64 instead of passing arguments and return values on the stack, though I guess it's to be seen what happens with multiple return values.

Re: Gollvm from Google

#49

Post by Mayzie »

meadori wrote: post #18

I am somewhat confused by this. The LLVM project already has an official Go frontend that lowers to LLVM IR: * https://llvm.org/svn/llvm-project/llgo/trunk/README.TXT

:-(

> You attempted to reach llvm.org, but the server presented a certificate signed using a weak signature algorithm (such as SHA-1). This means that the security credentials the server presented could have been forged, and the server may not be the server you expected (you may be communicating with an attacker).

Re: Gollvm from Google

#50

Post by zeusk »

weberc2 wrote: post #42
ndesaulniers wrote: post #31

Earlier quoted context omitted.

But go ir != llvm ir. The idea is you can leave behind optimizations passes and backend, simply maintaining a frontend, when you adopt the llvm ir and toolchain.

I don't disagree, but this is a different problem than the one cited above.

well, it is - because the existing architectural backends for llvm ir won't work with go's ir.
Post reply on HN