cmd/compile: riscv instruction bloat in hot loops due to large stack frame offsets

[lxq015]

Environment

• Go version: go1.25.6
• GOOS: linux
• GOARCH: riscv64
• GORISCV64: rva23u64

Background

I'm benchmarking Go programs across different architectures using golang.org/x/benchmarks (Bent suite). I've observed a consistent performance gap between RISC-V and ARM64, with RISC-V showing ~20-40% slower execution in many CPU-intensive workloads.

After profiling and analyzing the assembly output, I identified a systematic issue: RISC-V generates significantly more instructions in tight loops when accessing local variables with large stack offsets, while ARM64 handles the same code more efficiently.

Example: kanzi-go SBRT Transform

Go source (from github.com/flanglet/kanzi-go/transform/SBRT.go:207):

func (this *SBRT) Inverse(src, dst []byte) (uint, uint, error) {
// ... initialization ...
p := [256]int{} // Stack offset: SP + 2352
q := [256]int{} // Stack offset: SP + 304

for i := 0; i < count; i++ {  // Hot loop
    c := r2s[src[i]]
    qc := ((i & m1) + (p[c] & m2)) >> s  // ← Bottleneck
    p[c] = i
    q[c] = qc
    // ...
}

}
RISC-V assembly (loop body for line 207):
0x110906 ADDI $1176, X2, X19 # SP + 1176 → X19
0x11090a ADDI $1176, X19, X19 # X19 + 1176 → X19 (total: SP + 2352)
0x11090e SH3ADD X19, X18, X20 # p_base + (c << 3)
0x110912 MOV (X20), X21 # Load p[c]3 instructions to compute the address, repeated every iteration.

ARM64 assembly (same line):
0x148968 ADD $2360, RSP, R13 # RSP + 2360 → R13
0x14896c MOVD (R13)(R12<<3), R14 # Load p[c]1 instruction for the address calculation.

Root Cause

RISC-V's 12-bit immediate range (-2048 to +2047) forces the compiler to split large offsets into multiple ADDI instructions. Since the SSA backend currently treats these multi-instruction sequences as "cheap to rematerialize", it recomputes them inside loops instead of hoisting the base address calculation out.

Scope

This issue is not limited to kanzi-go. I've observed similar patterns across multiple Bent benchmarks:

• Invocation/interpreter/string_manipulation_size_50 (github.com/tetratelabs/wazero/internal/integration_test/bench)
• Invocation/interpreter/random_mat_mul_size_20 (github.com/tetratelabs/wazero/internal/integration_test/bench)
• Any code with large stack frames and tight loops

The cumulative effect across these workloads contributes significantly to RISC-V's performance gap.

Expected Behavior

The compiler should recognize that:

1. Large stack offset calculations (requiring 2+ instructions) are expensive
2. These calculations are loop-invariant
3. They should be hoisted before the loop and stored in a register

Ideal RISC-V output:

Before loop:

ADDI $1176, X2, X19
ADDI $1176, X19, X19 # X19 = SP + 2352 (p_base)

.Loop:
SH3ADD X19, X18, X20 # Use pre-computed p_base
MOV (X20), X21
# ... loop body ...
JMP .Loop

Question

Is this a known limitation? Are there plans to improve the cost model for RISC-V's limited immediate range, or to enhance LICM (Loop Invariant Code Motion) for architecture-specific multi-instruction sequences?

I'm happy to provide more detailed profiles or assist with testing potential fixes.

[lxq015]

Hi, @randall77 @cherrymui @markdryan @4a6f656c @mengzhuo @wangpc-pp
What are your thoughts/opinions on this? I'm interested in hearing any ideas or suggestions you might have.

[gabyhelp]

Related Issues

• cmd/compile: riscv performance degredation #74606 (closed)
• cmd/compile: poor spill decisions making code 14% slower #71868

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

[DanielMorsing]

Annoyingly, we won't know the offset from the stack pointer until after we've decided which values need stack slots, after register allocation proper. Since we don't know the offset, we cannot change whether a given value gets rematerialized depending on that offset.

Is there some sort of pre-stackalloc that we can do that would act as a heuristic? Large arrays seem like an obvious choice for marking as having offsets outside the immediate range.

[cherrymui]

We could choose to not rematerialize stack addresses on RISCV. The tricky part is that then we'd need to spill and reload the address if the register is clobbered (e.g. by a CALL), and reloading from a large offset of SP is also nontrivial.

For functions with large frames, we could choose to reserve a register to point to the middle of the frame, so the offsets are smaller (from either the SP or the reserved register) and fit in one instruction. We'd need some heuristics for the register allocator to choose to reserve the register before frame allocation, maybe based on the number of values. (Still tricky if it needs to live across a CALL.)

Is there some sort of pre-stackalloc that we can do that would act as a heuristic? Large arrays seem like an obvious choice for marking as having offsets outside the immediate range.

Maybe. We could choose to keep the array base address live, in a register if possible, and if it needs to spill, prioritize allocating its spill slot at a small offset from SP.

[JunyangShao]

@golang/compiler

[randall77]

It might make sense to put the big variables at the top of the stack frame, so that at least all of the small variables are likely to have small offsets from SP. (This would somewhat interfere with what we do now, which is put all the pointer-containing variables together.)

Just doing that probably doesn't help this particular issue, but might be generally useful.

We could choose to not rematerialize stack addresses on RISCV. The tricky part is that then we'd need to spill and reload the address if the register is clobbered (e.g. by a CALL), and reloading from a large offset of SP is also nontrivial.

Maybe. We could choose to keep the array base address live, in a register if possible, and if it needs to spill, prioritize allocating its spill slot at a small offset from SP.

I suspect it is faster to recalculate an address using just arithmetic than to load it, even from a hot place like the stack frame. So that might argue for some sort of hybrid value, which is "try harder to keep it in a register, but if it needs to spill, it can be rematerialized instead of spilled/restored".
And we can try to promote such values to registers before entering loops.