search for: llgo

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

...he 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, the monorepo contains a Go frontend called 'llgo' (in the llgo/ top level folder). It apparently hasn't been active since 2017 and before that it wasn't very active either (there were 13 commits in 2016 apparently, most of it minor fixes). I would propose that we remove it from the monorepo for the following reasons: * It is apparen...

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

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). > > I think providing a better alternative to libffi is al...

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

...r 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 via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > the monorepo contains a Go frontend called 'llgo' (in the llgo/ top > > level folder). It apparently hasn't been active since 2017 and before > > that it wasn't very active either (there were 13 commits in 2016 > > apparently, most of it minor fixes). > > > > I would propose that we remove it from the mon...

...gt;> you've mentioned. >>> >>> On Mon, Feb 10, 2020 at 8:42 AM Raphael Isemann via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > >>> > Hi all, >>> > >>> > the monorepo contains a Go frontend called 'llgo' (in the llgo/ top >>> > level folder). It apparently hasn't been active since 2017 and before >>> > that it wasn't very active either (there were 13 commits in 2016 >>> > apparently, most of it minor fixes). >>> > >>> > I woul...

...gt;>>> On Mon, Feb 10, 2020 at 8:42 AM Raphael Isemann via llvm-dev >>>>> <llvm-dev at lists.llvm.org> wrote: >>>>> > >>>>> > Hi all, >>>>> > >>>>> > the monorepo contains a Go frontend called 'llgo' (in the llgo/ top >>>>> > level folder). It apparently hasn't been active since 2017 and before >>>>> > that it wasn't very active either (there were 13 commits in 2016 >>>>> > apparently, most of it minor fixes). >>>>&g...

> Which projects do we put under this monolithic repository? The proposal at the moment is to include llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt, openmp, and parallel-libs. This is the set {llvm} plus the transitive closure of "projects that are version-locked to a project in the set", where the closure is taken over the set of all active LLVM subprojects. Projects that don't depend on a specific version of llvm...

...am planing to add projects into https://github.com/llvm-project/llvm-project in near future, possibly this week. Before doing that, I would like to ask users of it. 1st option is my preference in each paragraph. Let me know if you have other suggestions. * What is added? I will add; libunwind, llgo, openmp and parallel-libs. May I also add debuginfo-tests? * Will inactive projects be dropped? I won't do. * Where shall I push the new monorepo? - Create a new repository, like llvm-project-201705XX, or *-(number of repos) - Push new branches into the current llvm-project.git as dif...

Dear All I've made un update to the llvm to the latest. At configuration, I've met some new errors to me, like it needs lldb, lld, dragonegg, llgo and so. However, I've checked them and configuration went on. Now I'm stuck at build stage, specifically at dragonegg. First it could not find gmp.h, I've solved this by installing libgmp-dev. Now, it can't find auto-host.h. I couldn't solve this. Regards, Marwa Yusuf Teac...

...ations, pass manager, loop optimizations, etc TableGen Sanitizers Windows support Exception handling lld Clang, Libs, & Frontend tools Clang - parsing, LLVM IR generation, etc Static Analyzer OpenCL Clang Tools - clang tidy, clang rename parallel-libs Open MP libC++ llgo Please let us know ASAP if you are interested! In the rare event there are too many volunteers, we may combine topics at tables. -- The EuroLLVM'17 organization team PS. Heavily based on Tanya's email (see [0]). [0] http://lists.llvm.org/pipermail/llvm-dev/2016-October/106394.html -...

> On 21 July 2016 at 18:12, Justin Lebar <jlebar at google.com> wrote: > > llvm, clang, clang-tools-extra, lld, polly, lldb, llgo, compiler-rt, > > openmp, and parallel-libs. > > I really, *really* would like to see libc++ / abi / unwind. :) > > My reason is that, when building toolchains, the C++ ABI and unwinding > are fundamental parts of the run-time library, of which RT is only > part of. When...

...to relicense their changes under the LLVM license and submit them to the LLVM project.) The bindings would live in the LLVM tree under the bindings/go directory. One thing that I'd like to see come out of this is the contribution of an official Go frontend to the project, based on the existing llgo project [2] which uses these bindings. I am also submitting a patch with the initial version of the code to llvm-commits. For those familiar with Go, here are a few more details to explain how clients would use the bindings and how they would be integrated with LLVM. Clients would use a package...

...tack pointer*./  LLVM presumably has no support for this.  Without such support, however, GHC must spill all locals to memory at every call into the RTS.  It seems to me that this is why GHC cannot transform its output into SSA form: GHC must reify its stack. It would be nice (both for GHC and for llgo) if LLVM could be made to treat the stack pointer as a volatile register that may be changed by any function call.  In this model, the stack pointer needs to be treated the same as any other GC’d object — stack maps need to be emitted for it, and the RTS is allowed to relocate it. Would this be pr...

...ick and dirty tool in Go that takes two build trees and compares the sizes of the symbols in any object files found recursively in the build trees, while ignoring any symbols whose relocations point to different symbols. It can be found here: https://github.com/pcc/llvm-project/blob/sym-reloc-sizes/llgo/utils/benchcomp/main.go And it can be used like this: $ benchcomp sym_reloc_sizes builddir1 builddir2 | sort -n -k 4 If this seems useful I can see if I can find some time to contribute a tool based on this idea to LLVM in some form. Thanks, -- -- Peter -------------- next part --------------...

...AST headers are available > to external clients). > > 2. Write your library as a wrapper around that logic so that simple cases > can be handled without burdening other frontends with the subtleties of > Clang's AST data structures. > This is what I was thinking of doing for llgo in the long term. At the moment we have support for x86-64 only: http://llvm.org/klaus/llgo/blob/master/irgen/cabi.go. It would be nice to have a simplified API to TargetInfo, ideally with a C API that other languages to can easily bind to. Stephen, if you do go down that route, I'd be keen to...

...ssed at all: > libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 > libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan > libcxx-libcxxabi-x86_64-linux-ubuntu-tsan > libcxx-libcxxabi-x86_64-linux-ubuntu-gcc > libcxx-libcxxabi-x86_64-apple-darwin14-system-lib > lldb-x86_64-ubuntu-14.04-android > llgo-x86_64-linux > > Not pass in at least a month: > > llvm-clang-lld-x86_64-debian-fast > clang-native-mingw32-win7 > clang-x86_64-linux-selfhost-abi-test > clang-x64-ninja-win7-debug > perf-x86_64-penryn-O3-polly-detect-only > sanitizer-x86_64-linux-bootstrap > sanitizer...

...ect/llvm-project in near future, possibly this week. >> >> Before doing that, I would like to ask users of it. >> 1st option is my preference in each paragraph. Let me know if you have >> other suggestions. >> >> * What is added? >> I will add; libunwind, llgo, openmp and parallel-libs. >> May I also add debuginfo-tests? >> >> * Will inactive projects be dropped? >> I won't do. >> >> * Where shall I push the new monorepo? >> - Create a new repository, like llvm-project-201705XX, or *-(number of >>...