Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: provide a mechanism to disable architectures? #17123

Open
bradfitz opened this issue Sep 15, 2016 · 10 comments

Comments

@bradfitz
Copy link
Member

commented Sep 15, 2016

For build speed & binary size reasons, I would like to run make.bash with certain architectures disabled.

(my motivation: when I'm cross-compiling an ARM toolchain from Linux for #17105, there's no need for ppc64, mips64, s390x, arm64, 386, or even amd64 in my resulting binaries)

I started a prototype in https://golang.org/cl/29230 which defines build tags like "without_ppc64", "without_386", "without_s390x", etc.

The compiler and linker were easy. I decided to wait on cmd/asm until more discussion.

What do people think of something like this?

/cc @ianlancetaylor @mdempsky @randall77 @robpike @griesemer @josharian @rsc

@bradfitz bradfitz added the Proposal label Sep 15, 2016

@bradfitz bradfitz added this to the Go1.8Maybe milestone Sep 15, 2016

@randall77

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2016

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

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2016

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?

@mdempsky

This comment has been minimized.

Copy link
Member

commented Sep 15, 2016

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]()
}
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Sep 15, 2016

(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.

@mdempsky

This comment has been minimized.

Copy link
Member

commented Sep 15, 2016

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

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2016

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.

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2016

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.

@mdempsky

This comment has been minimized.

Copy link
Member

commented Sep 15, 2016

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?

@rsc

This comment has been minimized.

Copy link
Contributor

commented Oct 20, 2016

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.

@rsc rsc modified the milestones: Proposal, Go1.8Maybe Oct 20, 2016

@rsc rsc changed the title build: provide a mechanism to disable architectures proposal: build: provide a mechanism to disable architectures Oct 20, 2016

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2016

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.

@bradfitz bradfitz modified the milestones: Go1.9Maybe, Proposal Oct 20, 2016

@bradfitz bradfitz changed the title proposal: build: provide a mechanism to disable architectures build: provide a mechanism to disable architectures? Oct 20, 2016

@bradfitz bradfitz modified the milestones: Go1.10, Go1.9Maybe May 24, 2017

@bradfitz bradfitz modified the milestones: Go1.10, Unplanned Nov 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.