int8 exl3 GEMM (#1861): deleting the nt_off offset arithmetic -- cubin receipt
==============================================================================

Build: nvcc 13.0 (cuda-13), -arch=sm_89 -O3 -DEXL3_I8_ONLY_BITS=4, torch
2.12.1+cu130 headers.  4 bpw is the SERVED width, so these are the served
instantiations.  cuobjdump -sass, compared per instantiation, keyed on the
TEMPLATE ARGUMENTS rather than the mangled name -- the parameter list changes,
so the mangled name changes, and matching on it would compare nothing.

276 GEMM instantiations in the build.

A  baseline (HEAD before this commit): `+ nt_off` in the B address and
   `+ nt_off*16` in the epilogue's svh read.
B  this commit: both deleted, `nt_off` gone from the kernel signature.
C  probe: A with `nt_off = 0;` at kernel entry.  Signature UNCHANGED, so its
   parameter layout is byte-identical to A's.  This is what A compiles to
   when the offset is the value the binding already refuses to let it be
   anything but.
D  NULL CONTROL: A with the mul1 dp4a addend moved 0xfffffe03 -> 0xfffffe04
   (the uncentred value #1876 fixed).  A real change to the served decode.

1. A -> C   the offset was NOT dead code
------------------------------------------------------------------------------
   276 instantiations, 0 bit-identical, 276 moved, instruction delta -736

   EVERY served instantiation moves.  `nt_off` was a runtime parameter added
   into the B tile address on every k-tile and into the svh pointer on every
   epilogue store; at nt_off == 0 that is an add of a constant zero LOADED
   FROM PARAMETER SPACE, which the compiler cannot fold away because nothing
   in the kernel says the value is 0.  Representative:

       A:  LEA R19, R161, c[0x0][0x19c], 0x3      <- R161*8 + nt_off
       C:  IMAD.SHL.U32 R19, R161, 0x8, RZ        <- R161*8

   So this was never 'dead code behind a guard'.  It was live arithmetic
   executing with the value zero on every served call, and deleting it is a
   strict reduction.

2. C -> B   the deletion changes NOTHING BEYOND pinning the offset to 0
------------------------------------------------------------------------------
   instruction delta +0 over all 276 instantiations.
   raw:        0/276 bit-identical
   normalised: 276/276 bit-identical, 0 moved

   The raw difference is ONE constant-bank offset per w_scale reference:
   deleting the parameter frees its 4-byte slot, so every parameter after it
   moves down 4 (c[0x0][0x1a0] -> c[0x0][0x19c]).  Normalising that single
   shift -- in one direction, for offsets at or past 0x1a0 -- and nothing
   else, the two are bit-identical across every served instantiation.

   That is the claim this receipt exists to make: B is not 'a rewrite that
   happens to look right', it is EXACTLY what the code compiles to when the
   offset is 0, which is the only value the binding accepts.

3. A -> B   the change as landed
------------------------------------------------------------------------------
   276 instantiations, 0 bit-identical, 276 moved, instruction delta -736
   (2.67 instructions removed per instantiation.)

4. A -> D   NULL CONTROL: the instrument reports movement when there is any
------------------------------------------------------------------------------
   276 instantiations, 147 bit-identical, 129 moved, instruction delta +0

   And it reports movement in the RIGHT PLACE.  The addend is the mul1
   decode's; the mcg instantiations do not read it:

   codebook                   built   moved
   1 = mcg                      138       0
   2 = mul1                     138     129

   A control that moved everything would only show the comparator is alive.
   This one moves exactly the instantiations that read the constant that
   changed, and leaves the rest bit-identical -- so a null result in 1-3
   above means 'did not change', not 'did not look'.

