It looks like Google employee was working on this in his own time for several months (<a href="https://github.com/thanm/dragongo" rel="nofollow">https://github.com/thanm/dragongo</a>) and now the project has been "adopted" by Google/Go team.<p>By "adopted" I mean that:<p>* the code was moved to the same git hosting infrastructure that also hosts official Go compiler and libraries owned by Go team<p>* the license was changed from Apache to the same BSD license as Go compiler<p>* another Google employee is contributing to the code<p>* initial checkin was made by Russ Cox, who is pretty much the lead for Go project<p>All that implies that this has a blessing of the Go team
I am somewhat confused by this. The LLVM project already has an official Go frontend that lowers to LLVM IR:<p>* <a href="https://llvm.org/svn/llvm-project/llgo/trunk/README.TXT" rel="nofollow">https://llvm.org/svn/llvm-project/llgo/trunk/README.TXT</a>
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?
<i>"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."</i><p>Not sure I get it: so Gollvm (=llvm-goparse?) can be used as compiler, but not as a linker (yet?), so gccgo's linker can be used? Also, Go runtime and standard libraries can't be compiled with Gollvm? If standard libs can't be compiled, then how can I know if my app can be compiled?<p>I know a project named "llvm-go" was started quite long ago, and had somewhat slow (compared to gccgo) progress because of few, non-Google contributors (probably hobbyists); is this the same work? is it just still in progress, but somewhat more (how much?) advanced now?<p>Some additional googling shows a similarly named project (<a href="https://github.com/go-llvm/llvm" rel="nofollow">https://github.com/go-llvm/llvm</a>), which from its readme seems absorbed by LLVM proper, and is subtitled "LLVM bindings for [Go]" (<a href="http://llvm.org/svn/llvm-project/llvm/trunk/bindings/go/README.txt" rel="nofollow">http://llvm.org/svn/llvm-project/llvm/trunk/bindings/go/READ...</a>). Is this the same project, or something more, or something else? <i>[EDIT:]</i> Ok, based on the CONTRIBUTORS file, it's a totally different project, at least one question cleared. (<a href="https://go.googlesource.com/gollvm/+/master/CONTRIBUTORS" rel="nofollow">https://go.googlesource.com/gollvm/+/master/CONTRIBUTORS</a>)
> define hidden i64 @foo.bar() {<p>> entry:<p>> %"$ret0" = alloca i64<p>> store i64 0, i64* %"$ret0"<p>> store i64 1, i64* %"$ret0"<p>> %"$ret0.ld.0" = load i64, i64* %"$ret0"<p>> ret i64 %"$ret0.ld.0"<p>> }<p>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 machine?) and all of that just to return a 1.
I thought this project was very old and perhaps even abandoned? I wonder if I'm confusing it with a similar project, or perhaps this project was revived? Maybe I'm just mistaken...