I'm seeing this:
main
b1:
v1 = InitMem
v5 = VarDef {x} v1
v2 = SP : SP
v54 = MOVDaddr <[20]int> {x} v2 : R3
v137 = ADDconst <[20]int> [152] v54 : R4
v6 = LoweredZero [8] v54 v137 v5
v8 = VarDef {y} v6
v97 = MOVDaddr <[20]int> {y} v2 : R3
v116 = ADDconst <[20]int> [152] v97 : R4
v9 = LoweredZero [8] v97 v116 v8
v112 = MOVDconst [20] : R4
v16 = MOVDaddr <*[20]int> {x} v2 : R5
v17 = MOVDconst [0] : R6
Plain -> b2

This is being done to clear the storage (LoweredZero). Looks like the LoweredZero generates the last ADD of -8 to make the stdu work correctly. Perhaps that can't be combined because it is part of the LoweredZero, although I don't understand why the first two aren't combined.

The first two need a rule to combine ADDconst and MOVDaddr.
Something like

(ADDconst [c] (MOVDaddr [d] {sym} base)) -> (MOVDaddr [c+d] {sym} base)

The equivalent rule in AMD64.rules is:

(ADDQconst [c] (LEAQ [d] {s} x)) && is32Bit(c+d) -> (LEAQ [c+d] {s} x)

The add of -8 is done during ssa->prog so it can't be optimized away by SSA. The -8 is done there because if it was explicit in the SSA form, it would generate a pointer outside the bounds of the object it was pointing to. We can't let the GC see such a pointer.

This rule is already in PPC64.rules:

(ADDconst [c] (MOVDaddr [d] {sym} x)) -> (MOVDaddr [c+d] {sym} x)

Looks like it got added in 2f0b8f88
Is this fixed then?

Ooops I should have checked that first! It looks fine now except for the unnecessary add of -8, but I understand the reason why that can't go away. So this can be closed?