Stack slot permutation for locals

Technique

An assembly-level code-transformation technique in which the stack locations assigned to distinct local variables are reordered (permuted) provided that every read and write to those variables is updated consistently, so the program's observable data flow is preserved.

First seen 9/21/2026

Last seen 9/21/2026

Evidence 1 chunks

Wiki v1

WIKI

Stack slot permutation for locals

Stack slot permutation for locals is an instruction-level equivalence technique used when generating, transpiling, or validating low-level code (notably ARM assembly). It exploits the freedom a compiler or transpiler has to assign distinct local variables to distinct stack frame offsets, because the program remains semantically correct as long as every store and load that targets a given logical local variable is redirected to the same new offset.

How it works

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

2 connections

ARM targets ISA → 80% 1e

Stack slot permutation is demonstrated with ARM stack/frame-pointer addressing, indicating ARM as the target ISA.

Equivalent instruction sequences part of → 73% 1e

Permuting local variable stack slots changes addresses used but preserves program behavior, yielding equivalent sequences.

LINKED ENTITIES

2 links

ARM TARGETS_ISA Extracted graph relationship

Equivalent instruction sequences PART_OF Extracted graph relationship

CITATIONS

8 sources

8 citations — click to expand

[1] Local variables can be stored at different stack locations while maintaining correct access patterns, demonstrated by swapping the offsets of two stores (P8, edit distance 12). Guaranteed Guess: A Language Modeling Approach for CISC-to-RISC Transpilation with Testing Guarantees

[2] Stack frame offsets can vary while maintaining correct variable access, shown by ground truth strb r3, [fp, #-21] vs predicted strb r3, [fp, #-17] (P162, edit distance 4). Guaranteed Guess: A Language Modeling Approach for CISC-to-RISC Transpilation with Testing Guarantees

[3] Different registers can be chosen for temporary values while maintaining same data flow, e.g., mov r2 vs mov r3 (P108, edit distance 16). Guaranteed Guess: A Language Modeling Approach for CISC-to-RISC Transpilation with Testing Guarantees

[4] Multiple instructions can be combined into a single equivalent instruction, e.g., mov r3, r0; str r3, [fp, #-8] collapsing to str r0, [fp, #-8] (P135, edit distance 12). Guaranteed Guess: A Language Modeling Approach for CISC-to-RISC Transpilation with Testing Guarantees

[5] Memory allocation sizes can vary if sufficient for program needs, e.g., mov r0, #400 vs mov r0, #800 (P88, edit distance 23). Guaranteed Guess: A Language Modeling Approach for CISC-to-RISC Transpilation with Testing Guarantees

[6] Different instruction sequences can achieve the same logical result, e.g., cmp/and/rsblt vs rsbs/and/and/rsbpl (P103, edit distance 52). Guaranteed Guess: A Language Modeling Approach for CISC-to-RISC Transpilation with Testing Guarantees

[7] Constants can be loaded directly or from a literal pool, e.g., mvn r3, #-2147483648 vs ldr r3, .L8; .L8: .word 2147483647 (P69, edit distance 50). Guaranteed Guess: A Language Modeling Approach for CISC-to-RISC Transpilation with Testing Guarantees

[8] Compiler-generated symbol names can differ while referring to the same data, e.g., .word out.4781 vs .word out.4280 (P119, edit distance 6). Guaranteed Guess: A Language Modeling Approach for CISC-to-RISC Transpilation with Testing Guarantees