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

Andrew Wilkins
Tue, 25 Nov 2014 10:40:49 -0000

On Tue Nov 25 2014 at 18:30:08 Carlo Alberto Ferraris <cafxx at
strayorange.com>
wrote:

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

Yes, I'd like this to be an option. See:
  https://groups.google.com/forum/#!topic/llgo-dev/NaO36voIcMI
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074540.html

I don't think I ever recorded any benchmarking results from my experiment.

Cheers,
Andrew


> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "llgo-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to llgo-dev+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141125/6c547207/attachment.html>