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

cmd/compile: regression in recent change to improve LoweredMove on ppc64x #19907

laboger opened this issue Apr 10, 2017 · 1 comment


None yet
3 participants
Copy link

commented Apr 10, 2017

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go tip

What operating system and processor architecture are you using (go env)?

Ubuntu ppc64le

What did you do?

Built a golang from master, then tried to use it to do 'go get' on a ppc64le machine.

What did you expect to see?

Correct execution

What did you see instead?

go get -u
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]

goroutine 35 [running]:
panic(0x3b50a0, 0x684fd0)
/home/boger/golang/base/go/src/runtime/panic.go:531 +0x3e4
/home/boger/golang/base/go/src/runtime/panic.go:63 +0x64
/home/boger/golang/base/go/src/runtime/signal_unix.go:348 +0x258
created by net/http.(*http2Transport).newClientConn
/home/boger/golang/base/go/src/net/http/h2_bundle.go:6003 +0x568

After much debugging, I found that the generated code for LoweredMove when the target is unaligned and the size is 4 or 8 the golang assembler is generating incorrect instructions, i.e., it is setting fields in the instruction that shouldn't be set. In the above case, the bad code was found in processPing prior to the call to WritePing:

2ea5f8: 0c 00 a5 e8 ld r5,12(r5)
2ea5fc: 29 00 a1 f8 stdu r5,40(r1)
2ea600: 20 00 81 f8 std r4,32(r1)
2ea604: 01 00 80 38 li r4,1
2ea608: 28 00 81 98 stb r4,40(r1)
2ea60c: 1d f6 fe 4b bl 2d9c28 <net/http.(*http2Framer).WritePing>

Doing a stdu based off r1 is really bad at this point because the stack gets messed up. I found other cases where the assembler generates illegal instructions that result in a SIGILL at runtime. This happens because some loads and stores are DS form instructions, while others are D form instructions. Those with DS form instructions have a different sized field for the offset value, and require offsets that are a multiple of 4, but the D form instructions allow any offsets. The assembler was treating all loads and stores as D form instructions and was not checking the offset's alignment.

There are two parts to this problem which I plan to fix with 2 CLs:

  1. Fix PPC64.rules so it no longer generates asm with incorrect offsets when the load or store is a DS form. That fixes the regression, and I am continuing to test.
  2. Fix the assembler to detect the cases where loads and stores are DS form but are using incorrect offset values and generate an error.

There probably should be some additional testcases for this problem but not sure on the best place to put those.

@bradfitz bradfitz added this to the Go1.9 milestone Apr 10, 2017


This comment has been minimized.

Copy link

commented Apr 10, 2017

CL mentions this issue.

@gopherbot gopherbot closed this in b8d327a Apr 12, 2017

lparth added a commit to lparth/go that referenced this issue Apr 13, 2017

cmd/compile: fix PPC64.rules for LoweredMove
A recent performance improvement for PPC64.rules introduced a
regression for the case where the size of a move is <= 8 bytes
and the value used in the offset field of the instruction is not
aligned correctly for the instruction. In the cases where this happened,
the assembler was not detecting the incorrect offset and still generated
the instruction even though it was invalid.

This fix changes the PPC64.rules for the moves that are now failing
to include the correct alignment checks, along some additional testcases
for gc/ssa for the failing alignments.

I will add a fix to the assembler to detect incorrect offsets in
another CL.

This fixes golang#19907

Change-Id: I3d327ce0ea6afed884725b1824f9217cef2fe6bf
Reviewed-by: Carlos Eduardo Seo <>
Reviewed-by: David Chase <>

@golang golang locked and limited conversation to collaborators Apr 12, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.