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) <noreply@anthropic.com>

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

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