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

$ go version
go version devel go1.20-54182ff54a Fri Sep 9 20:29:05 2022 +0000 darwin/arm64

Does this issue reproduce with the latest release?

Yes

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

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/erifan01/Library/Caches/go-build"
GOENV="/Users/erifan01/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/usr/local/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/usr/local/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/erifan01/Desktop/go-master"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/erifan01/Desktop/go-master/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="devel go1.20-54182ff54a Fri Sep 9 20:29:05 2022 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/erifan01/Desktop/go-master/src/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vm/32796pv57pg0hxrpyyvkww040000gt/T/go-build897579779=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$ cat foo.go

package foo

var ll int = 1000

func foo1() {
        const N = 64
        a := make([]uint64, N)
        for i := 0; i < ll; i++ {
                for j := range a {
                        a[j] ^= 11
                }
        }
}

$ go tool compile -S foo.go | less

What did you expect to see?

The instruction MOVD $<unlinkable>..autotmp_3-512(SP), R2 is out of the loop.

What did you see instead?

The instruction MOVD $<unlinkable>..autotmp_3-512(SP), R2 is in the loop and executed every iteration.

Analysis:
This MOVD instruction is assembled from the MOVDaddr OP, which is a rematerializeable OP and in block b2, and the op is out of the loop. When it's used in block b10 and allocating a register to it, it's copied from b2 to b10, so it's moved into the loop. I think this is a general problem of allocating registers for rematerializeable OPs, independent of specific architecture, OS and specific OP.

One way I can think of is treating rematerializeable OP as usual OP when allocating registers, and when the register is not enough, clobber rematerializeable OP's registers first, and we do not need to load it from memory when unspilling the rematerializeable OP , just redo the OP because it is rematerializeable. This method is similar with that of Graal.

cc @randall77 @cherrymui