Sounds ok. I'm surprised it was that easy.
The SSA backend for all the architectures is still in there.

For my own understanding: Such a cross-compiled tool chain for ARM would run on ARM but not be able to cross-compile on ARM for another toolchain anymore, correct?

Seems ok to me.

But I'm doing a double-take looking at the doubly negated build tags: !without_amd64 . Can't we be positive?

For the compiler, I would think you only need to touch cmd/compile/main.go. E.g., have

s390x_main.go:

// +build !without_s390x

package main
import "cmd/compile/internal/s390x"
func init() {
    mains["s390x"] = s390x.Main
}

main.go:

package main
var mains[string]func()
func main() {
    mains[obj.GOARCH]()
}

(I saw the CL before the issue.)

I think adding build tags everywhere will be hard to maintain over time. mdempsky's idead sounds better to me if it works.

Oh, it looks like that's exactly the strategy you used for cmd/link even.

For my own understanding: Such a cross-compiled tool chain for ARM would run on ARM but not be able to cross-compile on ARM for another toolchain anymore, correct?

Seems ok to me.

Correct.

But I'm doing a double-take looking at the doubly negated build tags: !without_amd64 . Can't we be positive?

It's a little weird, but I can't think of a better way.

Oh, it looks like that's exactly the strategy you used for cmd/link even.

Yeah, I did that style for cmd/compile and cmd/link. I think cmd/asm might need different treatment.

But I wanted to make sure people were okay with this first.

I think cmd/asm just needs you to split up cmd/asm/internal/arch.go into GOARCH-specific arch.go files. arch.Set is the choke point there.

I'm okay with the idea if it's minimally intrusive like that. Do you have any numbers on how big a compile-time / executable-size win this is?

Let's punt this to next round.

Also, before committing to doing this, I'd like to see what the numbers are. You mention "build speed & binary size reasons". Please quantify those: how much faster does make.bash get, and how much smaller does the generated $GOROOT/pkg/tool dir get? It may be that the benefit is too small.

I agree about timing & need for numbers.

My prototype bitrot with a bunch of compiler changes & deletions, so I deleted my branch.

Can investigate later. I'll kick this to Go1.9Maybe with the understanding that we might close it without action, just so it's off the proposal dashboard.