cmd/compile: arm64 cross-compilation errors "branch too far"

[matt2909]

When using go1.5 to cross compile a large body of code on amd64/linux and targetting GOOS=linux GOARCH=arm64 I am getting the following errors:

00012 (my_code.go:246) BEQ 2907044
other_code.go:1: branch too far
00032 (my_code.go:246) BLS 2907044
other_code.go:1: branch too far
00224 (my_code.go:7) BNE 2907016
other_code.go:1: branch too far
00284 (my_code.go:8) BNE 2906988
other_code.go:1: branch too far
00344 (my_code.go:9) BNE 2906960
other_code.go:1: branch too far
00404 (my_code.go:10) BNE 2906932
other_code.go:1: branch too far
00464 (my_code.go:11) BNE 2906904
other_code.go:1: branch too far
00524 (my_code.go:12) BNE 2906876
other_code.go:1: branch too far
00584 (my_code.go:13) BNE 2906848
other_code.go:1: branch too far
00644 (my_code.go:14) BNE 2906820
other_code.go:1: too many errors

The code in question (name anonymised in this dump), is basically building a big slice of function pointers. Each function pointer points to a closure. The closure is generated within the same package, but there are a lot of closures (>5000).

This looks odd, the asm7.go code is being called with pc relative offsets greater than 19 bits. Happy to dig a bit further if someone can point me in the correct direction.

[bradfitz]

/cc @minux

[mwhudson]

Code that could be used to reproduce this would be helpful.

[matt2909]

I'll try and generate a test case for you tomorrow, I can't upload the code under test yet sadly

[matt2909]

Sorry for the delay... gist link to the generator code (it builds a tester.go with 20000 function stubs and a map pointing to them):

https://gist.github.com/matt2909/7c1c5880621f9c6d8775

To reproduce the compiler error I see on head:

$> go run generator.go > tester.go

/* ARM64 compiler breaks as follows */
$> GOOS=linux GOARCH=arm64 go build tester.go
//# command-line-arguments
./tester.go:1: branch too far
00012 (/xxxxx/tester.go:120015) BLS 1360280
./tester.go:1: branch too far
00172 (/xxxxx/tester.go:20007) BNE 1360252

/* AMD64 compiler behaves as expected and generates a tester executable */
$> GOOS=linux GOARCH=amd64 go build tester.go

[matt2909]

Let me know if that is sufficient for your purposes @mwhudson ?

[mwhudson]

I can reproduce the problem, so that's good. Unfortunately I'm a little confused about what's going on and don't really have time to investigate now.

I guess some code somewhere needs to switch to a model of loading the offset into a register and branching to that rather than attempting to encode the offset as an immediate.

[matt2909]

is it worth me taking a look? Is there anyway to understand the path though the compiler to the error? I couldn't find a good way of getting a stack trace (or any other trace) at the point of the error message.

[davecheney]

It will most likely be in cmd/internal/obj/arm64/asm7.go

On Tue, Oct 13, 2015 at 7:28 AM, Matt Horsnell notifications@github.com
wrote:

is it worth me taking a look? Is there anyway to understand the path
though the compiler to the error? I couldn't find a good way of getting a
stack trace (or any other trace) at the point of the error message.

—
Reply to this email directly or view it on GitHub
#12540 (comment).

[matt2909]

possibly the bit commented out about "very large branches" ?

[davecheney]

I'm sorry, I haven't looked at that code in months, but that does sound
like a smoking gun.

On Tue, 13 Oct 2015 07:57 Matt Horsnell notifications@github.com wrote:

possibly the bit commented out about "very large branches" ?

—
Reply to this email directly or view it on GitHub
#12540 (comment).

[matt2909]

anyway to get more context printed out as the compiler generates makes decisions on branching etc?

[mwhudson]

Nothing systematic I know about, I suspect this is the land of debugging by adding print statements.

[matt2909]

Do you know of any documents that explain some of the compiler phases, it's APIs or structs? Flying by fmt statements is fine if I have a map of the terrain