[LLVMdev] Proposal: add Go frontend subproject based on llgo

[Carlo Alberto Ferraris]

Just curious: are you considering the possibility of enabling LTO across user and runtime code? 
Since AFAIK the product of go build is almost always a statically-linked executable, I guess it would make sense (when doing an optimised build) to feed the runtime to the linker in IR form and let it run LTO.

Carlo

> On Nov 20, 2014, at 06:53, Peter Collingbourne <peter at pcc.me.uk> wrote:
> 
> Hi all,
> 
> I'd like to propose the contribution of a Go frontend subproject to the LLVM
> project, based on the existing llgo project at https://github.com/go-llvm/llgo .
> As with the previous contribution of the Go bindings, I have obtained
> permission from all llgo contributors whose code is part of this contribution,
> to contribute their changes to the LLVM project and relicense their changes
> under the LLVM license. I am also willing to be the code owner for the
> llgo subproject.
> 
> The frontend would live in the LLVM svn repository and if checked out into
> tools/llgo would build as part of the regular LLVM build (with CMake only). We
> would be keeping llgo compatible with top-of-tree LLVM, although I imagine
> this would be less burdensome than the other subprojects as llgo is written
> in Go and depends on the Go bindings previously contributed to LLVM.
> 
> llgo depends on certain third-party components, namely a copy of the Go
> standard library (libgo), a Go program analysis library (go.tools) and two
> library dependencies of the standard library (libbacktrace and libffi). These
> would be mirrored into the llgo repository under a third_party directory. They
> would retain their original licenses, which are BSD and GPLv3 with Runtime
> Library Exception (the latter only applies to a handful of header files;
> eventually we would seek to replace these).
> 
> As a first step, I have published:
> 
> http://reviews.llvm.org/D6327
> 
> with the initial code contribution. The mirrored third-party sources will be
> added later, as the diff would be too large to review. If there is consensus
> in the community, the next step I propose to take is to create the subproject
> in svn and check in the initial version of the code.
> 
> Any comments on this contribution are appreciated.
> 
> Thanks,
> -- 
> Peter
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev