What happens when a compiler peephole optimisation merges two load or store instructions that are not truly adjacent?

When a peephole optimiser merges instructions that are not really adjacent

A peephole optimiser works on tiny local patterns, so it assumes the instructions it combines are semantically equivalent to a single wider operation. When that assumption is wrong, the generated code can address the wrong slot, drop an update, or pair values that were never meant to be treated as one unit. The failure is subtle because the source still looks correct while the machine-level encoding no longer preserves the original memory relationship.

Why immediates and addressing rules make this fragile

The core hazard is not just “too much optimisation”, but aliasing at the encoding level. If a compiler treats two offsets as interchangeable because their bit patterns overlap in the instruction format, it may merge operations that should have stayed separate. In the reported case, a signed negative offset and a positive unsigned offset matched the same encoded immediate pattern, so the optimiser collapsed unrelated stores into one invalid paired instruction.

That kind of bug appears when the optimisation pass reasons about local structure without fully preserving the constraints of the target ISA. Load and store fusion is only safe when the architecture, alignment rules, sign interpretation, and instruction pairing semantics all line up. If any of those assumptions are off, the compiler can emit code that is internally consistent to the optimiser but invalid at execution time.

What this means for compiler correctness and debugging

The visible symptom is usually not a clean crash at the optimisation site. Instead, execution state is corrupted downstream: a memory write lands in the wrong place, a value appears stale, or a later instruction consumes data that was never intended to be combined. That makes the bug hard to diagnose because the fault may surface far from the actual miscompilation.

This is also why peephole issues are often architecture-specific. A transformation that is safe on one target may be wrong on another if the encoding width, signedness, or pairing rules differ. The same optimisation pass can therefore be correct in one backend and destructive in another, especially when the compiler reuses matching logic across instruction forms that look similar but are not semantically identical.

Risk and Threat Considerations

Miscompilation is primarily a correctness risk, but it becomes a security issue when corrupted writes affect control flow, privilege boundaries, or data integrity in sensitive code paths. If the optimiser can silently generate wrong memory accesses, the resulting defect may look like an application bug, a flaky test, or an intermittent hardware problem rather than a compiler defect.

Failure mechanism: A local rewrite merges instructions based on an overbroad equivalence, then emits an instruction form whose encoded offset or pairing semantics do not match the original operations.

Impact: The program can corrupt memory, overwrite the wrong object, or execute with invalid state, which may trigger crashes, silent data corruption, or security-relevant misbehaviour.

Practitioner Guidance

What to verify: Confirm that backend peephole rules are validated against the exact instruction encoding, including sign interpretation, alignment, and any pairing constraints. A test that only checks “same-looking offsets” is not enough if the ISA treats those offsets differently at decode time.

What practitioners underestimate: The dangerous part is not the merge itself, but the hidden assumption that two instructions are adjacent in the semantic sense, not just the textual or local-pattern sense. When that assumption is wrong, the optimiser may preserve shape while breaking meaning.

Decision rule: If a transformation depends on encoded immediates, treat it as an architecture-sensitive proof obligation, not a generic pattern rewrite. The safer approach is to block the optimisation unless the backend can prove equivalence for both operand interpretation and final machine encoding.

Practitioner takeaway: A peephole optimisation is only safe when the compiler proves semantic equivalence at the target-ISA level, not merely that two instructions resemble a mergeable pattern.

Related resources from NHI Mgmt Group

• What happens when a diagnostic app can load unverified plugins into a vehicle interface?
• What happens when pnpm resolves a crafted dependency name into a path outside the virtual store?
• What happens when an AI agent processes malicious instructions embedded in retrieved content?
• How should organisations balance convenience and security when deciding where to store two-factor authentication codes for everyday accounts?