llvm go frontend

[Hans Stimer]

Did anyone ever start a go llvm frontend project?

I'm not interested in reopening the llvm vs. roll-your-own-backend
debate; hopefully people will show self control.

[Russ Cox]

On Sun, Apr 17, 2011 at 15:17, Hans Stimer <hans....@gmail.com> wrote:
> Did anyone ever start a go llvm frontend project?

I'm not aware of one. The intent is that
http://code.google.com/p/gofrontend/ evolve
into something generic enough to support
multiple back ends.

Russ

[Hans Stimer]

Nice. How generic is it at this point?

On Apr 17, 4:52 pm, Russ Cox <r...@google.com> wrote:

[Dmitriy Vyukov]

Can't DragonEgg be attached to gccgo?
http://dragonegg.llvm.org/

[Ian Lance Taylor]

Hans Stimer <hans....@gmail.com> writes:

> Nice. How generic is it at this point?

Not particularly generic, but getting better. I'm actively working on
it. It's the kind of thing which somebody else could work on too. I
think it would be the fastest way to get an LLVM compatible Go frontend.

Ian

[Ian Lance Taylor]

Dmitriy Vyukov <dvy...@google.com> writes:

DragonEgg is an interesting hack which is useful for experimentation.
It shouldn't be mistaken for a proper compiler.

Ian

[Hans Stimer]

I had idea on getting llvm up and working. Use the go parser package
to generate an ast. Walk the ast and emit llvm instructions via ffi.
Any thoughts?


On Apr 17, 9:00 pm, Ian Lance Taylor <i...@google.com> wrote:

[Ian Lance Taylor]

Hans Stimer <hans....@gmail.com> writes:

> I had idea on getting llvm up and working. Use the go parser package
> to generate an ast. Walk the ast and emit llvm instructions via ffi.
> Any thoughts?

That may be feasible, though I think you will need the typechecker.

I've heard that there are already some Go LLVM bindings around.

Ian

[Hans Stimer]

Does the gofrontend share code with 6g, 8g, etc..? Lexer, parser, ast,
typechecker, etc...? Or is it a manual process to keep them synced?

On Apr 17, 10:21 pm, Ian Lance Taylor <i...@google.com> wrote:

[Russ Cox]

On Mon, Apr 18, 2011 at 13:15, Hans Stimer <hans....@gmail.com> wrote:
> Does the gofrontend share code with 6g, 8g, etc..? Lexer, parser, ast,
> typechecker, etc...? Or is it a manual process to keep them synced?

It shares no code with 6g and 8g, but it most
definitely shares code with gccgo. It is the source
(in the "upstream" sense) for gccgo's front end.

Russ

[Hans Stimer]

Is there any sharing of the go runtime libs between gccgo and [568]g?

Can gccgo use all the packages, even the ones that include c and asm?

On Apr 18, 10:17 am, Russ Cox <r...@google.com> wrote:

[Ian Lance Taylor]

Hans Stimer <hans....@gmail.com> writes:

> Is there any sharing of the go runtime libs between gccgo and [568]g?

Yes, gccgo copies the Go library from 6g et al with some modifications.

> Can gccgo use all the packages, even the ones that include c and asm?

Yes, though it uses its own C and asm code.

Ian

[Hans Stimer]

How do you build gofrontend?

~/projects/gofrontend/libgo $ ./configure
configure: error: cannot find install-sh, install.sh, or shtool in "."
"./.." "./../.."

I'm assuming it will need some gcc headers -- any particular version?

How do you test?


On Apr 18, 2:02 pm, Ian Lance Taylor <i...@google.com> wrote:

[Ian]

I had understood that Google's (still under development) Portable
Native Client (PNacl) project was based upon using LLVM bitcode. A lot
of effort seems to be going into developing PNacl and it looks like
Google views this as an important future technology.
If Go is going to work with PNacl, won't that mandate that Google (or
someone) develop an LLVM-bitcode-generating Go compiler at some point?
Maybe they don't envisage that sufficient people will want to use Go
for building web applications that run natively in the browser to
warrant the effort. Or perhaps Google is hoping the open source
community (or a summer-of-code project) might "pick up the ball" and
do the required development for them.

[Ian Lance Taylor]

Hans Stimer <hans....@gmail.com> writes:

> How do you build gofrontend?
>
> ~/projects/gofrontend/libgo $ ./configure
> configure: error: cannot find install-sh, install.sh, or shtool in "."
> "./.." "./../.."
>
> I'm assuming it will need some gcc headers -- any particular version?
>
> How do you test?

gofrontend is only useful in conjunction with the rest of gcc, and there
is a copy of gofrontend in the gcc repository.

http://golang.org/doc/gccgo_install.html

Ian

[Hans Stimer]

It appears that it is still dependent on tree, which makes it very
attached to gcc. How were you thinking of pulling that out? Making a
tree-a-like? Or, creating a bunch of classes like the go ast package?

On Apr 18, 8:56 pm, Ian Lance Taylor <i...@google.com> wrote:

[Ian Lance Taylor]

Hans Stimer <hans....@gmail.com> writes:

> It appears that it is still dependent on tree, which makes it very
> attached to gcc. How were you thinking of pulling that out? Making a
> tree-a-like? Or, creating a bunch of classes like the go ast package?

See backend.h. I just removed all the uses of gcc trees from
statements.cc. As I've tried to say before, this is something that
other people can work on too.

Ian

[Mortdeus]

I started working on this today because it seems like the most natural solution for my gocos2d project. However regarding PNACL ABI and the segmented stack attribute of goroutines im a bit unsure if they actually permit this type of behavior. I know that LLVM currently has some segmented stack support, but just glancing over the PNACL it seems they are only going to allow allocate? 

[Ian Lance Taylor]

On Sun, Jul 22, 2012 at 4:19 AM, Mortdeus <mort...@gocos2d.org> wrote:
> I started working on this today because it seems like the most natural
> solution for my gocos2d project. However regarding PNACL ABI and the
> segmented stack attribute of goroutines im a bit unsure if they actually
> permit this type of behavior. I know that LLVM currently has some segmented
> stack support, but just glancing over the PNACL it seems they are only going
> to allow allocate?

For details like that about PNaCl, you are going to have to ask the
PNaCl developers. As far as I know they do not read the golang-nuts
mailing list.

Ian

[Uriel]

Have you looked at llgo? It is a Go frontend for LLVM written in Go
itself, which IMHO is pretty cool:

https://github.com/axw/llgo

I wouldn't worry about the segmented stacks for now, it is not
essential to get Go going, and a solution can be found later.

Uriel