The three-multiply squaring is a real algebraic saving and a measured loss. Implemented, verified bit-exact against __int128 over 40M random values plus limb and power-of-two boundaries, then benchmarked on beast: 1072.9 vs 1137.7 MH/s over three interleaved rounds, 5.7% slower. It trades 6.7% of the kernel's widening multiplies for 11% more instructions -- 5 IMAD.WIDE in 56 instructions against the general product's 6 in 48 -- and four formulations (condition-code carry, compare carry, two mad.wide.u32 variants) all compiled to the same 5/56, so that is the floor rather than a tuning failure. Taken with the LAIR_INT_UNROLL result, the picture is consistent: this kernel is bound by instruction issue and by the cards' power envelope, not by multiply throughput or occupancy. Re-expressing the same work cannot win; only removing work can. Left as a comment so the next person does not spend the afternoon rediscovering it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ytCkttecH9SNTUEw8VT9D