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

Fredrik Ehnbom quarnster at gmail.com
Fri Nov 28 07:54:02 PST 2014


While I've been able to build gccgo and llgo both, I cannot use them as 
libgo doesn't build on darwin 
(https://code.google.com/p/gofrontend/issues/detail?id=18).

Is there any document/wiki/email describing the overlap(s) between gc, 
gccgo and llgo? Are the latter two affected by the golang.org/s/dev.cc 
effort?

/f

Den tisdagen den 25:e november 2014 kl. 11:40:50 UTC+1 skrev Andrew Wilkins:
>
> On Tue Nov 25 2014 at 18:30:08 Carlo Alberto Ferraris <
> ca... at strayorange.com <javascript:>> 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 <pe... at pcc.me.uk 
>> <javascript:>> 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
>> > LLV... at cs.uiuc.edu <javascript:>         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+u... at googlegroups.com <javascript:>.
>> 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/20141128/fbf1a8b7/attachment.html>


More information about the llvm-dev mailing list