cmd/compile/internal/ssa: regalloc handles arguments poorly

[DanielMorsing]

compiling this function with SSA

func bcopy(dst []byte, src []byte) {
    for i := 0; i < len(src); i++ {
        dst[i] = src[i]
    }
}

produces this output after regalloc

bcopy <nil>
  b1:
    v1 = InitMem <mem>
    v19 = Arg <*uint8> {dst} [0] : dst[*uint8]
    v32 = Arg <int> {dst} [8] : dst+8[int]
    v39 = Arg <*uint8> {src} [0] : src[*uint8]
    v34 = Arg <int> {src} [8] : src+8[int]
    v37 = MOVQconst <int> [0] : AX
    Plain -> b2
  b2: <- b1 b4
    v33 = Phi <mem> v1 v28
    v9 = Phi <int> v37 v31 : AX
    v36 = LoadReg <int> v34 : CX
    v5 = CMPQ <flags> v9 v36
    LT v5 -> b3 b5 (likely)
  b3: <- b2
    ULT v5 -> b6 b8 (likely)
  b6: <- b3
    v24 = LoadReg <*uint8> v39 : DX
    v20 = MOVBloadidx1 <byte> [0] v24 v9 v33 : BX
    v26 = LoadReg <int> v32 : BP
    v12 = CMPQ <flags> v9 v26
    ULT v12 -> b4 b9 (likely)
  b4: <- b6
    v25 = LoadReg <*uint8> v19 : SI
    v28 = MOVBstoreidx1 <mem> [0] v25 v9 v20 v33
    v31 = ADDQconst <int> [1] v9 : AX
    Plain -> b2
  b9: <- b6
    Plain -> b7
  b7: <- b8 b9
    v16 = CALLstatic <mem> {runtime.panicindex} [0] v33
    Exit v16
  b8: <- b3
    Plain -> b7
  b5: <- b2
    Ret v33

v34(len(src)) and v39(ptr(src)) both get loaded inside the loop body, even though their assigned registers are free for the entire function. I suspect it's because Arg values are handled as pre-spilled.

[crawshaw]

cc @randall77 @dr2chase

[randall77]

I'm working on this one.

[randall77]

It's more general than just args, any read-only use of a value within a loop has this problem at the moment.

[DanielMorsing]

Weird. I just tried

var blah = 1

func bcopy(dst []byte, src []byte) {
    y := blah
    for i := 0; i < len(src); i++ {
        dst[i] = byte(y)*src[i]
    }   
}

and that produces a load into y which is registerized across the entire function. If you make blah an argument, then it doesn't registerize well because y becomes a copy of an Arg value.

[randall77]

Right. Reading a global forces the load to happen before the loop starts.

[randall77]

This is fixed, probably by https://go-review.googlesource.com/c/20151/