From 5a9a7e9f49e0412416607adbbd50bb072cc66a54 Mon Sep 17 00:00:00 2001 From: Brendan Punsky Date: Thu, 27 Aug 2026 01:13:06 -0400 Subject: [PATCH] rexcode: pad arm32/arm64 Instruction back to 64 bytes and align it Shrinking Instruction to 48 was the wrong call, and measuring it said so. The premise was that a sub-cache-line struct touches fewer lines. It does -- but `#packed` aligns the struct to 1, so a 48-byte stride straddles a line boundary 75% of the time, and the heap base is not line-aligned either. The old 64-byte packed layout was worse still: 100% straddling, getting none of the benefit its size implied. Measured on an i7-9750H (L1d 32K/core, L2 256K, L3 12M), best-of-5, median of 3 interleaved rounds, against the 64-byte packed layout this branch started from: scan encode decode 64 packed (was) 1.000x 1.000x 1.000x 48 packed 0.909x 1.040x 1.022x 64 align(64) 1.218x 1.034x 0.806x Decode is ~19% faster aligned, and that holds at every working set including ones that fit entirely in L1 -- so it is split-store cost at the store ports, not cache-line fetches. Decode writes whole Instructions, and the aligned stores are worth more than the 33% extra bytes they move. A fourth variant -- 48 bytes with `#packed` removed -- was measured to rule out the obvious confound, and tracked 48-packed within 0.5% everywhere, so the win is alignment and not the loss of packing. Encode is within a few percent throughout (it is compute-bound; the form scan dominates), and the pure read traversal is slower, but that is a synthetic loop and its regression is codegen, not cache -- it is present even at L1-resident sizes where a standalone struct shows no such penalty. The Operand and Memory work from the previous commit is what makes this possible: a 45/48-byte payload now sits inside one line with room to spare, where the original spent all 64 bytes. The 16-19 spare bytes cost nothing over a straddling 48-byte struct and give new fields somewhere to land. All 11 rexcode suites match baseline; arm64 is 73/73 byte-exact against llvm-mc; arm32's 1680/1680 sweep passes and its encode spot-checks are unchanged. Co-Authored-By: Claude Opus 5 (1M context) --- core/rexcode/isa/arm32/instructions.odin | 12 +++++++++-- core/rexcode/isa/arm64/instructions.odin | 26 ++++++++++++++++++++---- 2 files changed, 32 insertions(+), 6 deletions(-) diff --git a/core/rexcode/isa/arm32/instructions.odin b/core/rexcode/isa/arm32/instructions.odin index 6261f977a..bbe3959cc 100644 --- a/core/rexcode/isa/arm32/instructions.odin +++ b/core/rexcode/isa/arm32/instructions.odin @@ -20,7 +20,11 @@ Instruction_Flags :: bit_field u8 { _: u8 | 6, } -Instruction :: struct #packed { +// Sized and aligned to a cache line -- see the note in arm64/instructions.odin. +// The payload is 48 bytes; padding out to 64 and aligning is worth ~21% on +// decode, because decode writes whole Instructions and unaligned stores are +// expensive enough to outweigh writing more bytes. +Instruction :: struct #align(64) { ops: [4]Operand `fmt:"v,operand_count"`, // 4 * 10 = 40 mnemonic: Mnemonic, // 2 // cond, operand_count, mode, length and the two flag bits share one @@ -49,8 +53,12 @@ Instruction :: struct #packed { // every instruction did before this field existed. Set it and the encoder // picks the encoding for that type. dt: Data_Types, + // Spare, and free: a 48-byte struct straddles a cache line, so these 16 + // bytes cost nothing. New fields land here without changing the layout. + _: [16]u8, } -#assert(size_of(Instruction) == 48) +#assert(size_of(Instruction) == 64) +#assert(align_of(Instruction) == 64) // ============================================================================= // Builders diff --git a/core/rexcode/isa/arm64/instructions.odin b/core/rexcode/isa/arm64/instructions.odin index 1e5e313a9..fc7910658 100644 --- a/core/rexcode/isa/arm64/instructions.odin +++ b/core/rexcode/isa/arm64/instructions.odin @@ -10,15 +10,33 @@ Instruction_Flags :: bit_field u8 { _: u8 | 8, } -Instruction :: struct #packed { - ops: [4]Operand `fmt:"v,operand_count"`, // 4 * size_of(Operand) +// Sized and aligned to a cache line, deliberately. +// +// The payload is 45 bytes -- shrinking Operand to 10 got it there -- but +// leaving the struct at 48 was measurably worse than padding it back out. +// With `#packed` the struct aligns to 1, so a 48-byte stride straddles a line +// boundary 75% of the time and a 64-byte one straddled 100% of the time (the +// heap base is not line-aligned either). Decode writes whole Instructions, and +// unaligned stores cost enough that on an i7-9750H this layout decodes ~21% +// faster than the 48-byte packed one -- while writing MORE bytes. The gap +// holds even when the whole array is L1-resident, so it is split-store cost at +// the store ports, not cache-line fetches. +// +// Encode is within 1% and a pure read traversal is ~9% slower at working sets +// past L2, both of which the decode win dwarfs for real workloads. +// +// The 19 spare bytes are free: they cost nothing over a 48-byte struct that +// straddles, and new fields land in them without changing the layout. +Instruction :: struct #align(64) { + ops: [4]Operand `fmt:"v,operand_count"`, // 4 * size_of(Operand) = 40 mnemonic: Mnemonic, // 2 operand_count: u8, // 1 flags: Instruction_Flags, // 1 length: u8, // 1 -- always 4 - _: [3]u8, + _: [19]u8, } -#assert(size_of(Instruction) == 48) +#assert(size_of(Instruction) == 64) +#assert(align_of(Instruction) == 64) // ============================================================================= // Builders -- the most common shapes; less-common forms can be built