cmd/compile: regalloc uses unreliable type data (like `v.Type.IsSigned()`) to choose the restore of spills

[Jorropo]

go version go1.28-devel_d1c1356637 Sun Jul 26 21:47:10 2026 -0700 linux/amd64

I guess it repros on all versions.

repro.go:

package main

var sink uint32

//go:noinline
func g(x uint32) { sink = x }

//go:noinline
func f(a, b uint32) int64 {
	p := a * b // MULW <uint32> — register holds sign-extended 32-bit result
	g(p)       // p live across the call → spilled as uint32 (4 bytes), restored with MOVWU
	return int64(int32(p)) // (MOVWreg (MULW)) elided at lower → uses restored (zero-extended) reg
}

func main() {
	r := f(0x8000, 0x10000) // product = 0x80000000
	if r != -2147483648 {
		println("BUG: got", r, "want -2147483648")
		return
	}
	println("ok")
}

> GOARCH=riscv64 go run repro.go 
BUG: got 2147483648 want -2147483648
> GOARCH=arm64 go run repro.go
ok
> GOARCH=amd64 go run repro.go
ok

[gabyhelp]

Related Issues

• cmd/compile: mips/mips64, multiply/divide results spilled from HI/LO corrupted w/ big stack frames #80563 (closed)
• cmd/compile: Rsh...x32 can get confused by garbage in the upper half of the register #79886 (closed)
• cmd/compile: sign extension wrong for paired 32-bit loads on arm64 #71759 (closed)
• cmd/compile: regalloc using multiple restores when one would do #74365

Related Code Changes

• cmd/compile: fix sign-extension merging rules

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

[Jorropo]

What happen here is that regalloc and ZeroUpper*Bits relies on type data, but the lowering step doesn't necessarily respect this.

My guess of how riscv64 expects us to do things:

• all values are always sexted to 64 bits.
• generic truncs and sext get lowered to literally nothing (as all users just use the argument of the trunc / sext instead)
• zext lowers to a mask to clear the higher bits
• restores (and loads more generally) always sext to respect the first rule
• unsigned shift right needs to clear the upper bits of the argument.*

*unlike the rest I don't think this is close optimal, but the goal should be to fix this misscompile, can be optimized later.

Edit: there are a couple more issues with this plan, like regalloc using too many bytes to spill a value after a trunc (since it'll use the original value size) but that minor.
Also now that I had a couple more minutes to think about it if we compile truncs to nothing absolutely all operations who do MSB → LSB caries need fixup. So I guess truncs should be a sext from the trunc's destination size to 64bits.
Also I'm assuming everything will maintain the cleanly sexted upper bits which needs to be checked.

[Jorropo]

cc @gopherbot please open backport issues, this causes unworkaroundable misscompilation issues on riscv64

[gopherbot]

Backport issue(s) opened: #80578 (for 1.25), #80579 (for 1.26).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[Jorropo]

Ok I somehow never knew that rv64 has W instructions similar to arm64 (altho they sext rather than zext).
I've starting going through the costs of always sign extending values and it's more annoying than I've thought.

It looks to me like riscv64 should "just" copy what we already do for arm64.

[gopherbot]

Change https://go.dev/cl/806340 mentions this issue: cmd/compile: do not elide riscv64 sign extension of unsigned values

[randall77]

My guess of how riscv64 expects us to do things:
all values are always sexted to 64 bits.

I don't think that's true. In any code where we compute 4-byte adds, for example, the upper 4 bytes get trashed (because we use an 8-byte ADD instruction).

I think we need to be more explicit about what exactly we guarantee here.

Currently, the arm64 ops file says:

//  - Integer types live in the low portion of registers. Upper portions are junk.

Which implies that a 4-byte spill+restore could arbitrarily corrupt the top 4 bytes.
But we're actually assuming something stronger with our current rules. Which is that the upper 4 bytes of a 4-byte type could be zeroed by a spill/store, not arbitrarily corrupted. I think we need to write that down explicitly somewhere.
And then write the corresponding thing down for riscv64.