看到一例 Go 编译器代码优化 bug 定位和修复解析这样一篇文章,感觉有些意思. 在此复现和记录

在Go 1.16版本下,是没有这个bug的(已修复). 参照gvm:灵便的Go版本管理工具 将Go版本切至有问题的1.13.5(或1.14.6)


➜  go versiongo version go1.13.5 darwin/amd64


package mainimport "fmt"func main() {    sli := []int32{1, 2, 3, 4, 5, 6}    // 如果是这种形式申明的sli, 仍然会出bug    //var sli []int32    //sli = []int32{1, 2, 3, 4, 5, 6}    // 如果是这种形式申明的sli, 则不会出bug    //sli := make([]int32, 0)    //sli = append(sli, 1, 2, 3, 4, 5, 6)    for k, v := range sli { //如果把sli改为 []int32{1, 2, 3, 4, 5, 6},也不会出bug        if k+1 < 1 { //去掉这个不会被执行进,没啥用的判断,则也不会出bug; 改为if k+2 < 2 {,也不会出bug            panic("")        }        fmt.Println("=========")        fmt.Println(k, v)    }}

执行后果:

=========0 1=========1 2=========2 3=========3 4=========4 5=========5 6=========6 622680=========7 192=========8 17477952=========9 0=========10 17733712=========11 0=========12 17475456=========13 0=========14 622792=========15 192=========16 17475584...


在线 查看&比对 给定程序编译产出的汇编后果. 该网站好评!


其实 Go 的编译器的实现中规中矩，相比于 GCC/Clang 等老牌编译器甚至有些简陋，许多优化并未实现


"Go 编译器提供了十分不便的性能，能够查看各个优化 pass 前后的 SSA IR，只须要在编译时，减少一个 GOSSAFUNC=xxx 环境变量即可，xxx 即为想要剖析的函数的名字，因为 Go 编译器外部的优化都是函数级别的。比方上图的例子，只须要运行 GOSSAFUNC=main go build ssaexample.go，编译器就会将 SSA IR 后果输入到当前目录的 ssa.html 中，用浏览器关上即可。"

用浏览器关上当前目录的 ssa.html:


执行 GOSSAFUNC=main go build 1.go

浏览器关上:


prove pass 的性能是对全局中 SSA 值的取值范畴做一个推断,这样就能够打消掉许多不必要的分支判断

Go 是内存平安的语言，所以所有的 slice 取元素操作都须要做一个查看，来判断取元素用的下标是否超出了 slice 的范畴，这个操作叫做 bound check。然而实际上，很多代码中在编译期就能确定这个下标是否越界，那么咱们就能够将本来须要在运行期做 bound check 的查看给打消掉，这步优化叫做 bound check elimination (即 BCE)

如下 这样的写法在Go源码中十分多

可参考 Go 官网规范编译器中所做的优化 之 Bounds Check Elimination


通过日志中的关键字, 能找到只有 findIndVar 和 addLocalInductiveFacts 这两个函数中会打这条日志，联合上下文和相干正文不难看出实际上问题是出在 addLocalInductiveFacts 这个函数上。addLocalInductiveFacts 具体是什么性能呢？从正文中不难看出，这里的性能是匹配到一种非凡的代码 pattern，即相似 repeat until 的逻辑，在循环开端判断某个条件是否成立


修复

具体

本文由mdnice多平台公布