cmd/compile: loop over []byte slowdown on amd64

[TocarIP]

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

go version devel +ef0e2af Mon Nov 6 15:55:31 2017 +0000 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/nfs/site/home/itocar/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/localdisk/itocar/gopath/"
GORACE=""
GOROOT="/localdisk/itocar/golang"
GOTMPDIR=""
GOTOOLDIR="/localdisk/itocar/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build447443283=/tmp/go-build -gno-record-gcc-switches"

/proc/cpuinfo:
model name : Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz

What did you do?
While comparing 1.9 vs tip performance I've noticed some performance regressions:
compress/flate/Encode/Twain/Huffman/1e4 92.8µs ± 0% 102.5µs ± 2% +10.50%
mime/quotedprintable/Writer 9.65µs ± 1% 11.05µs ± 2% +14.52% (p=0.000 n=8+8)

Bisecting points to 743117a
I didn't check if those regressions really cause worse code or is this is just an effect of code alignment/some other unrelated change.

[randall77]

@martisch

[TocarIP]

I've looked into mime/quotedprintable/Writer case.
Main problem is that base address of a load in reloaded on each loop iteration:
before:

inc    %rcx // cheap
....
mov    %rcx,0x28(%rsp) //  store
movzbl (%rcx),%ebx // load doesn't depend on store

after:

mov    0228(%rsp),%rdx // rdx is reloaded on each itteration
movzbl (%rdx,%rax,1),%ebx // depends on previous load

Advise from #22234 (I've commented loop.containsCall part) fixes this.

[gopherbot]

Change https://golang.org/cl/84055 mentions this issue: cmd/compile/internal/ssa: update regalloc in loops