MakeMove: hoist GET_COLOR(mv.pMoved)/FLIP(pos->uToMove) into uColor/xColor

Same CSE Scott started by hand -- traced it through the rest of the
function. pos->uToMove flips from uColor to xColor partway through
(the side-to-move toggle after the move is played), so every
GET_COLOR(mv.pMoved) collapses to uColor and every post-flip
FLIP(pos->uToMove) also collapses to uColor.

One line intentionally NOT hoisted: the unconditional
ASSERT(!InCheck(pos, GET_COLOR(mv.pMoved))) after the mv.uMove!=0
block. It's reachable via the null-move (mv.uMove==0) fast path, which
skips the uColor/xColor assignment entirely (goto clear_ep before
pPiece = mv.pMoved runs) -- a first version used uColor here
unconditionally and read uninitialized stack memory on that path,
caught via gdb after TryNullmovePruning's null-move search crashed
inside InCheck/KingPosition with a garbage color index.
GET_COLOR(mv.pMoved) stays correct either way (0 for a null move,
since MOVE is a union and mv.uMove==0 zeroes mv.pMoved too).

Did not extend the same hoist into UnmakeMove -- uColor would only be
used in the narrow en-passant-capture branch there, not worth paying
the assignment cost on every unmake for two call sites in a rarely-hit
branch.

Measured end-to-end (sd10 + sn5M, all three curated suites, before vs.
after): node counts and solve counts bit-for-bit identical (pure CSE,
zero behavior change once the null-move bug was fixed). Wall-clock
~1.0% faster overall, all 6 measurements faster, none slower --
MakeMove is the hottest function in the engine.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

0 files changed, 0 insertions, 0 deletions