5 ms·
"A common question that comes up is “why not just convert to the IR of {llvm,gcc,...} and go from there?” [...] I’m happy to be convinced otherwise - maybe we
by torrance 12y ago
"A common question that comes up is “why not just convert to the IR of {llvm,gcc,...} and go from there?” [...]
I’m happy to be convinced otherwise - maybe we should throw our effort into getting frame maps out of {llvm,gcc,...} and figuring out how to configure the backend (e.g. which optimizations to turn on) to make it compile quickly."
Wouldn't this be worthwhile just to be able to use some of the LLVM tools (debuggers, performance analysers, etv.) alone? Not to mention optionally being able to compile with more expensive optimisations.
- jsd1982 12y agoLLVM and its tools are implemented in C++. The Go team just underwent a large effort to remove their dependency on C code. A reasonable assertion can be made that given this C code removal, a large and complex C++ dependency like LLVM is unlikely to be in their sights for inclusion into the compiler. Perhaps this wouldn't be an /entirely/ unreasonable to do; I can imagine a `cgo` binding to LLVM existing for this purpose. Speaking of which, I wonder what the fate of `cgo` is with this compiler code migration from C to Go.
- andrewchambers 12y agoLLVM already has official go bindings in the main repo, also, the llgo go compiler uses these bindings. Unfortunately building it all was a pain for me, and the resulting binary was 80 megs which seemed a bit ridiculous (Go had to statically link all of llvm into one monolith).
- deleted 12y ago[deleted]
- andrewchambers 12y agoLlvm takes longer to clone in git than downloading and building the entire go tool chain from scratch. A full build with llvm plus clang takes 30 minutes or so on my pc. A full go build takes 10 seconds. The go team is small and fast. Taking on that kind of baggage is unnecessary.