State of llgo in monorepo?

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 apparently unmaintained.
* It only supports a long outdated Go version (1.5 while latest is 1.13 or so).
* It doesn't build (at least on my machine) due to runtime errors (the
build log is really unhelpful in telling me what actually went wrong).
In general the build system is kinda flawed as it seems to just
manually run 'make' as a single custom build step (even with a -GNinja
* It contains a full copy of Mark Twain's novel "The Adventures of Tom
Sawyer". It gets really tiring to blacklist this file on my desktop
search engine as it otherwise constantly comes up in unrelated
searches for words that are by accident in this novel.
* The sources of multiple third party libraries are copied into its
third party directory. It would be nice not to have random code in the
LLVM repo under a different license than LLVM.
* It's the only reason why we maintain some Go support in LLVM's CMake
(like llvm_add_go_executable ).


- Raphael

Thanks for bringing this up! Strong +1 from me for all the reasons
you've mentioned.

Yep - delete it. If someone wants it back they can resurrect it from version control & explain why it’s worth adding back in.

Calling pcc real fast :slight_smile:


Sure, that’s fine with me.


OK. I’ll get it.


Done thusly:

echristo@athyra ~/r/llvm-project> git push
936d1427da1…372bfc65deb master → master

Do we still need these:

We still have code written in go in the tree, in llvm/bindings/go/.


So just to summarise what happened outside the mailing list:

  • We removed llvm-go
  • We also removed/fixed several things that referenced llvm-go in the following days.
  • We reverted all of that (apparently to test LLVM’s Go bindings with llvm-go instead of system Go)

So from what I understand the only reason llvm-go is in tree is to test the bindings? It’s also not clear to me why we can’t use the normal go compiler for testing them (like we test the ocaml bindings with the system ocamlc).

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 running go programs with the desired set of environment variables.

From the comment in the file:

This tool lets us build LLVM components within the tree by setting up a $GOPATH that resembles a tree fetched in the normal way with “go get”.

(FWIW, I had the exact same reaction as you, before realizing the above.)

Thanks for clarifying. I had skimmed the commits and had the exact same (wrong) impression. :slight_smile:


Can someone add a mention about the llgo removal to the release notes?


“The llgo frontend has been removed for now, but may be resurrected in the future.”





Committed in 03c8e1cc7efabd122294e1cd670fba6d544f2831. Thanks!

Thank you!