cmd/compile: on `AMD64` slow instruction sequence to Zext a < register size instruction output

[Jorropo]

Go version

go version go1.26-devel_b3e316e269 Sun Oct 26 22:49:49 2025 +0100 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='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v3'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/tmp/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/hugo/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2204351525=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/hugo/k/go/src/go.mod'
GOMODCACHE='/home/hugo/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/hugo/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
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='go1.26-devel_b3e316e269 Sun Oct 26 22:49:49 2025 +0100'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Compile the f function:

func branchlessBoolToInt(x bool) (r uint) {
 if x { r = 1 }
 return
}

func f(x, y uint) uint {
 return branchlessBoolToInt(x != y)
}

What did you see happen?

        TEXT    command-line-arguments.f(SB), NOSPLIT|NOFRAME|ABIInternal, $0-16
        ... ; metadata
        CMPQ    BX, AX
        SETNE   CL
        MOVBLZX CL, AX
        RET

What did you expect to see?

        TEXT    command-line-arguments.f(SB), NOSPLIT|NOFRAME|ABIInternal, $0-16
        ... ; metadata
        XORL CL, CL
        CMPQ    BX, AX
        SETNE   CL
        RET

[Jorropo]

The first sequence is slower because CMPQ + SETNE is fused in a single ALU uop.
Then MOVBLZX is an other data-dependent ALU uop executing right after.

Other compilers (LLVM, GCC, ...) use the second sequence which incurs a single ALU uop (CMPQ + SETNE).
The XORL CL, CL is handled by the register renaming unit.
Sadly XOR touches the flags making this non trivial since SETcc is always gonna want the flags from something else.
In practice most cases are this trivial and a bit of amd64 dedicated code should handle this well.

[gopherbot]

Change https://go.dev/cl/715045 mentions this issue: cmd/compile: add intrinsics for subtle.ConstantTime{Select,ByteEq,Eq,LessOrEq}

[gopherbot]

Change https://go.dev/cl/715045 mentions this issue: crypto/subtle,cmd/compile: add intrinsics for ConstantTimeSelect and *Eq

[gabyhelp]

Related Issues

• cmd/compile: regalloc can leave unused instructions after performing rematerialization and removing the only dependent #67911 (closed)
• cmd/compile: amd64 carry flag spilling uses SBBQ + NEGQ instead of SETCS #68961
• cmd/compile: eliminate redundant zeroing after lower pass #47107 (closed)
• cmd/compile: more boolean optimizations #17905 (closed)
• cmd/compile: In bits.Len(x|1), compiler doesn't realize argument is never zero #51964 (closed)
• cmd/compile: Optimise branches that could be behind other branches, to avoid running those branches when known to be false #46711
• runtime: simplify right shift and zero test #30272
• cmd/compile: suboptimal compilation of reflect.isZero #64222
• cmd/compile: Unnecessary register high-bytes rezeroing after unsigned right shift #19712
• cmd/compile: Instruction split on amd64 #56476 (closed)

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

[gopherbot]

Change https://go.dev/cl/731620 mentions this issue: cmd/compile: on AMD64 add an already zero argument for SETcc to write into

[Jorropo]

Actually I don't know if CMP & SETcc can be fused. It make sense, would be cheap to implement in the CPU but I don't remember reading about it anywhere.
I know CMP & Jcc is fused but it's vastly more common than any usage of SET to begin with.

If they could we always generate the MOVL 0$, AX right before the SET which would prevent that.
Same issue with CMP + CMOV.

My latest CL means CMP + SET + extension is 2 instead of 3 latency cycles which is a good performance gain.
But if we could fuse them it would go down to 1 latency cycle.