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

[Peter Collingbourne]

On Thu, Nov 20, 2014 at 11:32:45AM -0500, Tom Stellard wrote:
> On Wed, Nov 19, 2014 at 01:53:17PM -0800, Peter Collingbourne 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).
> > 
> 
> Why do libbacktrace and libffi need to be mirrored in the llgo
> repository?  Can't llgo link with system versions of these libraries?

There are not necessarily going to be suitable system versions of these
libraries available. GCC seems to treat them more like implementation details
of their own runtime libraries. The libbacktrace library, for example, is
not installed on my machine in a central location, rather it appears in a
version-specific directory under /usr/lib/gcc.

The libffi that we use may also have Go-specific patches (e.g. [1]), so we
cannot use the system one.

Thanks,
-- 
Peter

[1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01009.html