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

31–40 of 51 posts

Re: Gollvm from Google

#31

Post by ndesaulniers »

weberc2 wrote: post #15
zeusk wrote: post #11

Earlier quoted context omitted.

A big problem intermediate code solves is that, you don't need a big monolithic compiler for both front-end language parsing and back-end architecture instructions. They call it MxN problem, so instead of MxN combinations of architectures and languages in a monolithic compiler - you get M+N components where M handle the language parsing etc.. while N handle the conversion from the single intermediate language/instruc…

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.

Re: Gollvm from Google

#34

Post by TheDong »

pinpeliponni wrote: post #27
theparanoid wrote: post #25

Earlier quoted context omitted.

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

There's no reason GC couldn't work on GPUs. No one just has bothered implementing it yet.

http://wiki.c2.com/?SufficientlySmartCompiler

Yeah, and a GPU could also just happen to give you the right answer in an O(1) hashtable lookup

Re: Gollvm from Google

#36

Post by zik »

akavel wrote: post #7

"At the moment llvm-goparse is not capable of building the Go libraries + runtime (libgo), which makes it difficult/unwieldy to use for running actual Go programs. As an interim workaround, I've written a shim/wrapper script that allows you to use llvm-goparse in combination with an existing GCCGO installation, using gccgo for the runtime/libraries and the linking step, but llvm-goparse for any compilation." Not sure…

I think you're thinking of llgo, not go-llvm.

Re: Gollvm from Google

#38

Post by wyldfire »

weberc2 wrote: post #15
zeusk wrote: post #11

Earlier quoted context omitted.

A big problem intermediate code solves is that, you don't need a big monolithic compiler for both front-end language parsing and back-end architecture instructions. They call it MxN problem, so instead of MxN combinations of architectures and languages in a monolithic compiler - you get M+N components where M handle the language parsing etc.. while N handle the conversion from the single intermediate language/instruc…

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 likely to contribute a backend implementation to LLVM than golang.

Re: Gollvm from Google

#39

Post by cyphar »

kibwen wrote: post #17
krylon wrote: post #16

Earlier quoted context omitted.

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

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

Re: Gollvm from Google

#40

Post by zeusk »

loeg wrote: post #13
zeusk wrote: post #9

> define hidden i64 @foo.bar() { > entry: > %"$ret0" = alloca i64 > store i64 0, i64* %"$ret0" > store i64 1, i64* %"$ret0" > %"$ret0.ld.0" = load i64, i64* %"$ret0" > ret i64 %"$ret0.ld.0" > } Can someone knowledgeable with Go, explain what's happening here? Why does it store a 0 and then a 1 in "$ret0"? Why does it allocate a single integer on the stack? (is it because this is just intermediate code for a virtual m…

> Why does it store a 0 Go language semantics define that variables receive a zero initialization.[0] > and then a 1 in "$ret0"? The 1 is because the code explicitly stores a 1 :-). Clearly the output code has not been through an optimization pass. [0]: https://gobyexample.com/variables

but if you look at the code, there isn't a "variable" to be initialized - the function is supposed to return a constant/literal one.
Post reply on HN