cmd/compile: memcombine should learn alignment of byte slices - hard mode - arithmetic

[Jorropo]

Go version

go version devel go1.25-b38415d7e9 Sat Feb 15 21:47:27 2025 -0800 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='0'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='riscv64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/tmp/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/hugo/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3509629757=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/hugo/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/hugo/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GORISCV64='rva20u64'
GOROOT='/home/hugo/k/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/hugo/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/home/hugo/k/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.25-b38415d7e9 Sat Feb 15 21:47:27 2025 -0800'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Compile:

package a

import "encoding/binary"
import "unsafe"

func xorByte(s []byte, xor byte) {
        for ; len(s) != 0 && uintptr(unsafe.Pointer(unsafe.SliceData(s)))%8 != 0; s = s[1:] {
                s[0] ^= xor
        }
        x := uint64(xor)
        packed := x | x<<8 | x<<16 | x<<24 | x<<32 | x<<40 | x<<48 | x<<56
        for ; len(s) >= 8; s = s[8:] {
                binary.NativeEndian.PutUint64(s, binary.NativeEndian.Uint64(s)^packed)
        }
        for ; len(s) != 0; s = s[1:] {
                s[0] ^= xor
        }
}

What did you see happen?

The two calls to binary.NativeEndian.* compiles a series of 8 bits loads, shifts and bitwise OR & AND.

What did you expect to see?

64 bits load and store is used.

[Jorropo]

This is similar to #71778.
I've never wrote go code with the expectation this would be optimized altho I've done many times in C. This will probably change when we get SIMD intrinsics.

I guess I could extend prove to learn this kinds of things.

[Jorropo]

My example is particularly hard because when exiting the first loop the alignment is in fact not known at compile time but this will only happen if length is zero then the 8 bytes loop body wont execute.
If we can optimize this it would be enough to work with given some code massaging:

package a

import "encoding/binary"
import "unsafe"

func xorByte(s []byte, xor byte) {
        if len(s) == 0 { return }
        for ; uintptr(unsafe.Pointer(unsafe.SliceData(s)))%8 != 0; s = s[1:] {
               if len(s) == 0 { return }
                s[0] ^= xor
        }
        x := uint64(xor)
        packed := x | x<<8 | x<<16 | x<<24 | x<<32 | x<<40 | x<<48 | x<<56
        for ; len(s) >= 8; s = s[8:] {
                binary.NativeEndian.PutUint64(s, binary.NativeEndian.Uint64(s)^packed)
        }
        for ; len(s) != 0; s = s[1:] {
                s[0] ^= xor
        }
}

[gabyhelp]

Related Issues

• cmd/compile: memcombine should learn allignement of byte slices - easy mode - types #71778
• cmd/compile: Use wide integer load/store instructions if possible #11819 (closed)
• cmd/compile: memcombine does not combine stores separated by OpLocalAddr #70300 (closed)
• cmd/compile: multiple LittleEndian.Uint* calls on the same buffer block load merging #52708 (closed)
• cmd/compile: encoding/binary.PutUint32 generates unaligned data storage on arm64 arch #59856 (closed)
• cmd/compile: stringtoslicebytetmp optimization on unescaped slice #38501 (closed)
• cmd/compile: unsafe conversion from slice to struct pointer generates worse code on amd64 than on 386 #65330
• test/codegen: brittle on multi-line go expressions that get coalesced into single instructions #25061 (closed)
• cmd/compile: handle 64-bit masks better on 32-bit systems #32781 (closed)
• Signed non-negative divide by power of 2. #44530 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}