similar to: [LLVMdev] Proposal: bindings for the Go programming language

> Importing this path would cause 'go get' to check out LLVM plus the bindings > from SVN using the mechanism described in [3]. We would check index.html > files into the www repository to support this. > > There doesn't seem to be a good way to build complex C++ projects such as LLVM > using 'go get', so there is a script (update_llvm.sh) that builds LLVM and

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

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

On Thu, Nov 20, 2014 at 12:19:06AM +0100, Joerg Sonnenberger wrote: > On Wed, Nov 19, 2014 at 01:53:17PM -0800, Peter Collingbourne wrote: > > 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). >

Done thusly: echristo at athyra ~/r/llvm-project> git push To github.com:llvm/llvm-project.git 936d1427da1..372bfc65deb master -> master On Mon, Feb 10, 2020 at 10:02 AM Eric Christopher <echristo at gmail.com> wrote: > OK. I'll get it. > > -eric > > On Mon, Feb 10, 2020 at 9:58 AM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Sure,

"The llgo frontend has been removed for now, but may be resurrected in the future." Thoughts? -eric On Tue, Aug 25, 2020 at 2:18 PM Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can someone add a mention about the llgo removal to the release notes? > > Thanks, > Hans > > On Fri, Feb 14, 2020 at 3:40 PM James Y Knight via llvm-dev >

Sure, that's fine with me. Peter On Mon, Feb 10, 2020 at 9:57 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Calling pcc real fast :) > > -eric > > On Mon, Feb 10, 2020 at 9:49 AM David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Yep - delete it. If someone wants it back they can resurrect it from >>

Nope, it wasn't all reverted -- the llgo implementation remains deleted. There's been some confusion borne out of unfortunate naming -- only the file "llvm/tools/llvm-go/llvm-go.go" was reinstated. Despite its confusing name, this tool is *not* a go implementation, and has effectively nothing to do with llgo. It's only a tiny utility script used by the llvm build process for

Hi folks, Sometimes I make a change to the compiler that causes a binary size regression and I need to track down where that regression came from. One relatively naive way of doing this is to take two build trees, one compiled with the old compiler and another compiled with the new compiler, and then compare the symbol sizes (st_size) in the final output files in each build tree. The problem with

On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Mon, May 9, 2016 at 3:17 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Mon, May 9, 2016 at 2:33 PM,

On Tue, May 10, 2016 at 3:03 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On May 9, 2016, at 4:42 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter

On Tue, May 10, 2016 at 11:45 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 9, 2016 at 4:42 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>> >>> On Mon, May 9, 2016 at 3:38 PM, Peter

On Mon, May 9, 2016 at 3:17 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Mon, May 9, 2016 at 2:33 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Mon, May 9, 2016 at 1:53 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Fri, May 6, 2016 at 2:10 PM, David

Yep - delete it. If someone wants it back they can resurrect it from version control & explain why it's worth adding back in. On Mon, Feb 10, 2020 at 9:17 AM Jonas Devlieghere via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for bringing this up! Strong +1 from me for all the reasons > you've mentioned. > > On Mon, Feb 10, 2020 at 8:42 AM Raphael Isemann

On Fri, Feb 25, 2011 at 02:55:33PM -0500, Ken Dyck wrote: > The address space mechanism is used by some code generators to > differentiate between physical memory spaces. The PIC16 code generator > uses address spaces 0 and 1 to select between its RAM and ROM spaces. > And X86 uses address space 256 for GS and 257 for FS. In the back end > for a dual-harvard DSP that I've been

On Fri, May 6, 2016 at 2:09 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Fri, May 6, 2016 at 1:55 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Fri, May 6, 2016 at 1:21 PM, Duncan P. N. Exon Smith < >> dexonsmith at apple.com> wrote: >> >>> >>> > On

> On 2014 Dec 5, at 10:53, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Fri, Dec 05, 2014 at 09:35:22AM -0800, Duncan P. N. Exon Smith wrote: >> >>> On 2014-Dec-05, at 00:39, Peter Collingbourne <peter at pcc.me.uk> wrote: >>> >>> On Thu, Dec 04, 2014 at 06:44:36PM -0800, Duncan P. N. Exon Smith wrote: >>>> As of

On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> wrote: > Hello, > > I think that the approach of using a section to record address > significance is a good one. I'm guessing it will have its own section > type and format? If it does would it make sense to try and submit this > to the GABI https://groups.google.com/forum/#!forum/generic-abi as

> On Oct 24, 2016, at 1:07 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: > The specific change I have in mind is to allow !range metadata on GlobalObjects. This would > be similar to existing !range metadata, but it would apply to the

On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> > wrote: > >> Hello, >> >> I think that the approach of using a section to record address >> significance is a good one. I'm guessing it will have its own section >> type and format? If