SSA FTW!

[Keith Randall]

We have now reached the point where we'd like to get ports of the SSA backend going for all the other architectures.  The goal is to get them all done by the 1.8 freeze (Nov. 1).  Then we get to delete the old backend!

To that end, Cherry has been working on an ARM (32-bit) port of the SSA backend.  It is getting close to complete and has in the process generated a blueprint to follow for the other architectures.

The general idea is to get the compiler working a bit at a time.  Pick a simple function you're fond of.  I like Fibonacci.  Add code to the compiler until it generates correct code for just that function (using GOSSAFUNC to compile just that function with SSA and all others with the legacy backend).  Then pick another, slightly larger function and do it again.  Repeat until we have a complete compiler.

The first arm32 CL was by me (https://go-review.googlesource.com/21000).  It shows where you need to hook into the compiler to make it use the SSA backend instead of the normal backend for your architecture.  It also shows how to add rules files and opcodes files for your new architecture.

Cherry made lots of followon CLs, like:

https://go-review.googlesource.com/c/22654/

https://go-review.googlesource.com/c/22856/

https://go-review.googlesource.com/c/23093/

A hopefully complete list of CLs hangs off this issue: https://github.com/golang/go/issues/15365

Work is now proceeding on the arm32 port on the dev.ssa branch.  Feel free to work there as well.  We'll merge back to main after 1.7 is out.

Cherry is planning on working on the arm64 port after he finishes the arm port.  David Chase is planning on working on the ppc64 ports.  Don't let that dissuade you from working on those ports also if you'd like, the more the merrier.

No one has currently committed to the 386, s390, or mips64 ports.

Please ping me if you'd like to work on any of these ports.  We'll set up tracking bugs, organize code reviews, etc. to  help organize the effort.  I'd also like to get folks interested in this effort together at Gophercon at some point.

[Aram Hăvărneanu]

I am the person responsible for doing the arm64 SSA conversion. E.g.
ARM pays me to do that.

--
Aram Hăvărneanu

[Aram Hăvărneanu]

Also, re: SPARC64. The current WIP port which I plan to integrate
early into the 1.8 cycle uses the old back-end. The plan is to switch
to SSA for SPARC64 too during the 1.8 cycle, but I want to integrate
it first using the old back-end.

--
Aram Hăvărneanu

[alb]

Are partial contributions (i.e. no-commitment) welcome? I was bored
this evening so I changed gc to make it able to SSA-compile
    func sum(a, b int) int {return a+b}
on 386. It's a start, but I know nowhere near enough about 386 assembly
to be the one "committed" to the 386 SSA backend.

[Keith Randall]

Absolutely, partial contributions are excellent.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[alb]

Thanks, I have two quick questions before I decide if the patch is worth sending.

1) is
    env SSATEST=true GOARCH=386 GOSSAFUNC=sum go build test.go
and then running ./test (NB: on a amd64 machine) a valid way to test the 386 SSA backend?

2) is the 386 backend to be implemented as a completely separate package (as you did
for arm32) even if we already have amd64? Am I right to assume that in that case a number
of rules and parts of ssa.go can be copied from amd64's ssa.go ?

[Keith Randall]

On Wed, Jun 8, 2016 at 12:18 PM, alb <alb.do...@gmail.com> wrote:

Thanks, I have two quick questions before I decide if the patch is worth sending.

1) is
    env SSATEST=true GOARCH=386 GOSSAFUNC=sum go build test.go
and then running ./test (NB: on a amd64 machine) a valid way to test the 386 SSA backend?

Yes, that sounds correct.

 

2) is the 386 backend to be implemented as a completely separate package (as you did
for arm32) even if we already have amd64? Am I right to assume that in that case a number
of rules and parts of ssa.go can be copied from amd64's ssa.go ?

Yes, and yes.  If parts of amd64 are large you could also export them and import them from x86/ssa.go.

[Bill O'Farrell]

Myself and my team at IBM wish to work on the s390x SSA port. In fact we've already started some preliminary work, so you can assign me to that.

[lab...@linux.vnet.ibm.com]

I have started some initial work on ppc64x.  I tried to follow what was done for the ARM SSA port, and got it to the point of building successfully and get it to successfully build hello.  Not sure about some of the details of the design or how to write rules so working with someone else who knows more on that would be helpful.  (Generated code was worse.)  I had to set aside this work to fix a few bugs but should be able get back to it and to check in what I've done next week or so.

[David Chase]

Fantastic, and glad to have your help.

It's officially my responsibility to see that this one gets done, but if you share the load that is a-ok all round.

I opened a bug for PPC (LE), it can just be PPC.

https://github.com/golang/go/issues/16010

I was planning to start on it in earnest after next week (next week is devoted to seeing whether 1.7 interacts badly with Delve in any way) but if you have any questions or CLs I will make them a priority.

[lab...@linux.vnet.ibm.com]

Hi,

I have gotten bogged down trying to fix a golang bug where the text sections get too big on ppc64le.  I have made a few fixes but then hit the next bug.  I have a general understanding what should happen but I'm not that familiar with how golang does it so debugging is taking a long time while I'm learning what it should do.

But, I have a few questions on how to check in the SSA changes.  What is the process for checking into the ssa branch and what is the criteria?  Last I tried it built OK and seemed to build a hello program OK but I don't remember if it ran.  Do I need an issue?  If I can just check in what I have I can do that soon.

[Keith Randall]

On Fri, Jun 24, 2016 at 5:41 AM, <lab...@linux.vnet.ibm.com> wrote:

Hi,

I have gotten bogged down trying to fix a golang bug where the text sections get too big on ppc64le.  I have made a few fixes but then hit the next bug.  I have a general understanding what should happen but I'm not that familiar with how golang does it so debugging is taking a long time while I'm learning what it should do.

But, I have a few questions on how to check in the SSA changes.  What is the process for checking into the ssa branch and what is the criteria?  Last I tried it built OK and seemed to build a hello program OK but I don't remember if it ran.  Do I need an issue?  If I can just check in what I have I can do that soon.

Changes to the ssa branch should be mailed, reviewed, and checked in just like the main branch.  The code freeze for 1.7 does not apply to the ssa branch.

all.bash should still work with your changes.  The SSA backend for your port should be guarded by an environment variable that is off by default (see cmd/compile/internal/gc/ssa.go:shouldssa).

[Keith Randall]

For those at gophercon, let's try to get those working on ssa together tomorrow (Tuesday) for lunch.  No real agenda, just wanted to see where people are and coordinate a bit.

[Keith Randall]

Ok, let's try to meet right after the last morning talk for lunch.  Come find me stage right right after the talks end.