cmd/compile: go1.7beta2 performance regression (floats and arrays)

[taruti]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.6.2 linux/amd64
go version go1.7beta2 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/taru/go"
GORACE=""
GOROOT="/usr/lib/go-1.6"
GOTOOLDIR="/usr/lib/go-1.6/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/taru/go"
GORACE=""
GOROOT="/tmp/go"
GOTOOLDIR="/tmp/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build453968611=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?

Try some float32 heavy code with arrays on 1.7beta2, saw a problem and reduced it to a self contained example:

go get github.com/taruti/float_degradation
cd ...
go test -test.bench=.

Or fancier
while date; do go test -test.bench=. >> /tmp/old.txt; GOROOT=/tmp/go /tmp/go/bin/go test -test.bench=. >> /tmp/new.txt; done

1. What did you expect to see?

1.7beta2 producing as good or better code than 1.6

1. What did you see instead?

benchcmp /tmp/old.txt /tmp/new.txt 
benchmark                 old ns/op     new ns/op     delta
BenchmarkOptimize16-2     33310269      41841404      +25.61%
BenchmarkOptimize16-2     33337835      41889202      +25.65%
BenchmarkOptimize16-2     33341432      42080975      +26.21%
BenchmarkOptimize16-2     33280481      41913719      +25.94%
BenchmarkOptimize16-2     33236073      41971975      +26.28%
BenchmarkOptimize16-2     33274075      41866159      +25.82%

[dgryski]

Related to #15925 ?

[taruti]

At least related probably. -gcflags -ssa=0 restores 1.6 like performance.

I think that array zeroing is here not the fault, most time is spent in
linearBin that takes a *[16]float32 but does not zero any array.

This code is simplified from machine generated code.

[ianlancetaylor]

CC @randall77 @josharian

[randall77]

Looks like the register allocator is spilling some stuff to the stack that is unnecessary.
I don't really understand why it is doing that. Will fix for 1.8.

[rsc]

ping @randall77

[gopherbot]

CL https://golang.org/cl/32442 mentions this issue.

[odeke-em]

@randall77 would you consider this a duplicate, or perhaps superset of #16141? Both deal with floats, regressions and approximately same title.

[randall77]

I would not be surprised if they had the same underlying cause (partial SSE register stalls). Not sure though.

[josharian]

Reproduced with tip at 638ebb0. Better than 1.7 and 1.8, but not 25% better.

name \ time/op  17           18           tip
Optimize16-8    21.9ms ± 3%  22.5ms ± 2%  21.2ms ± 1%

[mdempsky]

Still repros for me: BenchmarkOptimize16-4 is about 28% slower at 1.10 than 1.6 on my workstation.