cmd/compile: suboptimal zeroing of multiple registers on amd64

[fice-t]

Go version

go version go1.26-devel_e88be8a Sun Nov 23 09:07:32 2025 -0800 linux/amd64

Output of go env in your module/workspace:

Workspace is `go.godbolt.org` on `x86-64 gc (tip)` as above.

What did you do?

[Code+output tested here]

Compile this simplified example:

var someError error

func f(w bool) (int, int, int, error) {
	if w {
		return 0, 0, 0, someError
	}
	return 1, 2, 1, nil
}

What did you see happen?

The output for 0, 0, 0 above uses XORL and two MOVQ:

        XORL    AX, AX
        MOVQ    AX, BX
        MOVQ    AX, CX

What did you expect to see?

All zeroing of registers here should use XORL.

[gabyhelp]

Related Issues

• cmd/compile: on `AMD64` slow instruction sequence to Zext a < register size instruction output #76066
• cmd/compile: prefer to cheaply rematerialize than copy registers #24132 (closed)
• cmd/compile: eliminate redundant zeroing after lower pass #47107 (closed)
• cmd/compile: unnecessary zeroing of register on arm #8474 (closed)
• cmd/compile: unnecessary instructions generated #29892 (closed)
• cmd/compile: double zeroing and unnecessary copying/stack use #67957 (closed)
• cmd/compile: omit zeroing of named return value when possible #4750
• cmd/compile: small struct initialization code is suboptimal because of redundant zeroing #59021 (closed)
• cmd/internal/obj: remove MOV $0 -> XOR "optimization" #22325 (closed)

Related Discussions

• Redundancies in amd64 code generation

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

[Jorropo]

It's pretty minor, using MOVQ is just as fast, the register renaming unit can rename all three in one cycle even if there is a dependency.
However because we encode a 64bits MOVQ it uses 3 bytes vs a 32bits op due to the 1 byte REX prefix so we should still change it.

[cherrymui]

Have you measured the performance? Or is it just about the binary size? Thanks.

[fice-t]

Mainly the encoding size, but I filed this just because I noticed it while looking at assembly output for other issues.

I was also going to open a related issue to use XXXL instead of XXXQ where possible; should that instead be merged into this issue?

For example, the above's return 1, 2, 1 uses MOVQ where it could use MOVL:

        MOVL    $1, AX
        MOVL    $2, BX
        MOVQ    AX, CX  ; <-- could be MOVL as AX is 32-bit

[cherrymui]

Using the same issue is fine.

[gopherbot]

Change https://go.dev/cl/731640 mentions this issue: cmd/compile: on amd64 use 32bits copies for 64bits copies of 32bits values