cmd/compile: using unsafe.Pointer will affect BCE optimization

[zigo101]

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

go version go1.7.3 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build745042352=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?

https://play.golang.org/p/NYFLIpw7fp

What did you expect to see?

BCE works for line 52.

What did you see instead?

BCE doesn't work for line 52.

[bradfitz]

Please write complete bug reports and answer the questions.

Your "What did you do?" section is lacking. You must have done more than that to see whether BCE was working. What are you using to evaluate the compiler's decisions?

[randall77]

The reason the bounds check is not eliminated is that you're taking the address of a and b. That turns a bunch of optimizations off that would otherwise apply. When you write b (b = b[:len(a)]), the compiler doesn't know that you're not also writing a (it could with better alias analysis, but that doesn't exist yet). So it doesn't know that the len(a) used in b = b[:len(a)] is the same len(a) as the one used in the range statement.

A better way to check for aliasing is if &a[0] == &b[0]. It doesn't use unsafe and it allows BCE to work.

I'm going to close this bug for now. There are no plans for alias analysis at the moment, and if/when we do get there this issue can be revisited.

[zigo101]

glad to know it is intended.