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

Peter Collingbourne
Thu, 20 Nov 2014 20:35:50 -0000

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