llgo vs llvm go arch backend?

[ste...@zen.ly]

Hi All,

In the past year or so, the number of Go architecture backends have exploded. It seems llgo is taking a different approach, but could it be possible to create a Go architecture backend that would emit llvm ir (perhaps via go-llvm) ?

I've also seen that llgo talks to go's SSA, so perhaps this approach is rendered moot?

I may be completely wrong about my assumptions, but I'd love my projects to compile to llvm ir.

[Andrew Wilkins]

On Thu, 1 Dec 2016 at 06:35 <ste...@zen.ly> wrote:

Hi All,

In the past year or so, the number of Go architecture backends have exploded. It seems llgo is taking a different approach, but could it be possible to create a Go architecture backend that would emit llvm ir (perhaps via go-llvm) ?

With LLVM IR, you still need to encode target-specifics such as the ABI. So if you mean a backend that emits architecture-independent LLVM IR, no.

I've also seen that llgo talks to go's SSA, so perhaps this approach is rendered moot?

I don't really understand this question. llgo uses golang.org/x/tools/go/ssa as input, and translates that to LLVM IR.

 

I may be completely wrong about my assumptions, but I'd love my projects to compile to llvm ir.

You can compile to LLVM IR using llgo; the LLVM toolchain always involves IR. Normally you wouldn't see it, because it's an intermediate representation (!) -- but you can capture the IR by passing the right command line flags (e.g. "-emit-llvm").

Cheers,

Andrew