Revalidated the ATCM handler result across four placements, and it holds (#632)

The handler comparison in #630 measured one alignment, which is the mistake
that made the cache benchmark in this example report 24% or 0% for identical
silicon. The handler body is now generated at four offsets within a cache
line, all four are measured, and the figures are reported per placement.

The claim survives. Mean cycles for the handler body:

    loop offset      code RAM    ATCM
    0                     523     383
    16                    534     377
    32                    539     375
    48                    521     383

ATCM is faster at every placement, by about 28%, and the two sets of means do
not overlap. Worst case improves as well, 510 against 694.

Two things worth recording beyond the headline.

The handler measurement is only mildly alignment sensitive, 3.5% across
placements in code RAM and 2% in ATCM, quite unlike the cache loop's two
modes. So this comparison was less fragile than the cache one, and #630's
direction was right even though its method was not defensible. The absolute
numbers differ from #630 because the body now sits behind a placement wrapper
that adds a call; the comparison is internally consistent either way.

Both variants also report identical cache sweeps, 0 and 0 and 240 and 240,
which settles the regression this branch's predecessor appeared to show. That
apparent regression was the single-alignment probe moving between its two
modes, not anything about ATCM.

One copy of the logic is kept: the wrappers inline a single always_inline
implementation, so the four placements cannot drift apart.

Assisted-by: Claude Code (Opus 5) <[email protected]>

0 files changed, 0 insertions, 0 deletions