go - 为什么for-range的行为取决于slice结构的大小？

我在玩这段代码

main_var.go

package main

func main() {
    const size = 1000000

    slice := make([]SomeStruct, size)
    for _, s := range slice { // line 7
        _ = s
    }

}

type_small.go

package main

type SomeStruct struct {
    ID0 int64
    ID1 int64
    ID2 int64
    ID3 int64
    ID4 int64
    ID5 int64
    ID6 int64
    ID7 int64
    ID8 int64
}

我注意到，如果我向该结构添加另一个64位int64 ID9(总计10 * 8字节= 80字节)，则for循环会变慢。

如果我比较程序集，它会添加指令以复制元素

// with 9 int64 (72 bytes)
    0x001d 00029 (main_var.go:6)    LEAQ    type."".SomeStruct(SB), AX
    0x0024 00036 (main_var.go:6)    MOVQ    AX, (SP)
    0x0028 00040 (main_var.go:6)    MOVQ    $1000000, 8(SP)
    0x0031 00049 (main_var.go:6)    MOVQ    $1000000, 16(SP)
    0x003a 00058 (main_var.go:6)    CALL    runtime.makeslice(SB)
    0x003f 00063 (main_var.go:6)    XORL    AX, AX
    0x0041 00065 (main_var.go:7)    INCQ    AX
    0x0044 00068 (main_var.go:7)    CMPQ    AX, $1000000
    0x004a 00074 (main_var.go:7)    JLT    65
    0x004c 00076 (main_var.go:7)    MOVQ    32(SP), BP
    0x0051 00081 (main_var.go:7)    ADDQ    $40, SP
    0x0055 00085 (main_var.go:7)    RET
    0x0056 00086 (main_var.go:7)    NOP
    0x0056 00086 (main_var.go:3)    CALL    runtime.morestack_noctxt(SB)
    0x005b 00091 (main_var.go:3)    JMP    0

// with 10 int64 (80 bytes), it added DUFFCOPY instruction
    0x001d 00029 (main_var.go:6)    LEAQ    type."".SomeStruct(SB), AX
    0x0024 00036 (main_var.go:6)    MOVQ    AX, (SP)
    0x0028 00040 (main_var.go:6)    MOVQ    $1000000, 8(SP)
    0x0031 00049 (main_var.go:6)    MOVQ    $1000000, 16(SP)
    0x003a 00058 (main_var.go:6)    CALL    runtime.makeslice(SB)
    0x003f 00063 (main_var.go:6)    MOVQ    24(SP), AX
    0x0044 00068 (main_var.go:6)    XORL    CX, CX
    0x0046 00070 (main_var.go:7)    JMP    76
    0x0048 00072 (main_var.go:7)    ADDQ    $80, AX
    0x004c 00076 (main_var.go:7)    LEAQ    ""..autotmp_7+32(SP), DI
    0x0051 00081 (main_var.go:7)    MOVQ    AX, SI
    0x0054 00084 (main_var.go:7)    DUFFCOPY    $826 # <-- copy the element
    0x0067 00103 (main_var.go:7)    INCQ    CX
    0x006a 00106 (main_var.go:7)    CMPQ    CX, $1000000
    0x0071 00113 (main_var.go:7)    JLT    72
    0x0073 00115 (main_var.go:7)    MOVQ    112(SP), BP
    0x0078 00120 (main_var.go:7)    ADDQ    $120, SP
    0x007c 00124 (main_var.go:7)    RET
    0x007d 00125 (main_var.go:7)    NOP
    0x007d 00125 (main_var.go:3)    CALL    runtime.morestack_noctxt(SB)
    0x0082 00130 (main_var.go:3)    JMP    0

我想知道为什么即使在两种情况下都未使用slice元素的情况下，较大结构(> 80字节)的行为却不同。

最佳答案

我发现这是由于SSA优化。
在lower传递期间更明确。此过程将“中间表示”更改为机器特定的组件。

在writebarrier(在lower之前1步)处，两种结构尺寸的指令仍然相同。

        v22 (7) = Phi <*SomeStruct> v14 v45
        v28 (7) = Phi <int> v16 v37
        v23 (7) = Phi <mem> v12 v27
        v37 (+7) = Add64 <int> v28 v36
        v39 (7) = Less64 <bool> v37 v8
        v25 (7) = VarDef <mem> {.autotmp_7} v23
        v26 (7) = LocalAddr <*SomeStruct> {.autotmp_7} v2 v25
        v27 (+7) = Move <mem> {SomeStruct} [72] v26 v22 v25  # <-- copy operation

如您所见，v27上有Move操作。

但是，在lower通过之后，指令有所不同。

带有9个int64(72字节)的
v22 (7) = Phi <*SomeStruct> v14 v45 v28 (7) = Phi <int> v16 v37 v23 (7) = Phi <mem> v12 v27 v37 (+7) = ADDQconst <int> [1] v28 v25 (7) = VarDef <mem> {.autotmp_7} v23 v26 (7) = LEAQ <*SomeStruct> {.autotmp_7} v2 v44 (7) = CMPQconst <flags> [1000000] v37 v32 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [8] v2 v31 (+7) = ADDQconst <*SomeStruct> [8] v22 v29 (+7) = MOVQload <uint64> v22 v25 v24 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [40] v2 v15 (+7) = ADDQconst <*SomeStruct> [40] v22 v46 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [56] v2 v35 (+7) = ADDQconst <*SomeStruct> [56] v22 v21 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [24] v2 v17 (+7) = ADDQconst <*SomeStruct> [24] v22 v39 (7) = SETL <bool> v44 v42 (7) = TESTB <flags> v39 v39 v30 (+7) = MOVQstore <mem> {.autotmp_7} v2 v29 v25 v41 (+7) = MOVOload <int128> [8] v22 v30 v20 (+7) = MOVOstore <mem> {.autotmp_7} [8] v2 v41 v30 v34 (+7) = MOVOload <int128> [24] v22 v20 v19 (+7) = MOVOstore <mem> {.autotmp_7} [24] v2 v34 v20 v33 (+7) = MOVOload <int128> [40] v22 v19 v38 (+7) = MOVOstore <mem> {.autotmp_7} [40] v2 v33 v19 v47 (+7) = MOVOload <int128> [56] v22 v38 v27 (+7) = MOVOstore <mem> {.autotmp_7} [56] v2 v47 v38

带有10个int64(80字节)的，它使用DUFFCOPY设备优化MOVE
v22 (7) = Phi <*SomeStruct> v14 v45 v28 (7) = Phi <int> v16 v37 v23 (7) = Phi <mem> v12 v27 v37 (+7) = ADDQconst <int> [1] v28 v25 (7) = VarDef <mem> {.autotmp_7} v23 v26 (7) = LEAQ <*SomeStruct> {.autotmp_7} v2 v44 (7) = CMPQconst <flags> [1000000] v37 v32 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [8] v2 v31 (+7) = ADDQconst <*SomeStruct> [8] v22 v29 (+7) = MOVQload <uint64> v22 v25 v39 (7) = SETL <bool> v44 v42 (7) = TESTB <flags> v39 v39 v30 (+7) = MOVQstore <mem> {.autotmp_7} v2 v29 v25 v27 (+7) = DUFFCOPY <mem> [826] v32 v31 v30 # <---

此优化是由于rule on rewriteAMD64.go
match: (Move [s] dst src mem) cond: s > 64 && s <= 16*64 && s%16 == 0 && !config.noDuffDevice result: (DUFFCOPY [14*(64-s/16)] dst src mem)

在稍后阶段(elim unread autos)，SSA优化可以检测到临时变量autotmp_7没有被使用并且可以将其删除。对于带有DUFFCOPY的较大结构，情况并非如此

我写了更多细节here