Inside the Cost: Where Silicon Turns Tag Checks into Cliffs

ARM MTE’s interface is standardized more tightly than its internal machinery. The focus here is the hardware path between a pointer tag and a completed memory operation: where tags are stored, how they reach the cache and checking logic, and which core-specific choices turn a routine check into a performance cliff. The value of this view is diagnostic. It lets us distinguish metadata work that every implementation must accommodate from bottlenecks that a better design can remove.

The ISA leaves room beneath the same interface

The processor must compare a pointer’s tag with the tag for the addressed memory granule, but the architecture does not dictate one physical storage scheme. That matters because tag metadata has to travel through a memory hierarchy designed primarily for data. It consumes storage, cache capacity, bandwidth, queues, and coherence work even when every tag matches and no error is reported.

The Pixel 8 and 9 cores studied by the authors are close to Arm’s reference approach. Four tag bits are needed for every 16 bytes of physical memory, so roughly 3% of physical memory is reserved for tags. A cache line that carries 64 bytes of data also brings the associated tag information into the cache. On a cache miss, the implementation performs independent reads for the data and its tags. The tag is small, but its existence creates another part of the miss path and another piece of state for the cache hierarchy to manage.

AmpereOne makes a different choice. It places the tags in bits normally used for error-correction information and extends a 64-byte cache line to 66 bytes, using the additional bytes for tags. The processor can retrieve data and associated tags with one physical-memory query and can maintain coherence with one transaction rather than the two transactions required by the reference-style path described for Pixel. That design avoids the Pixel-style cache-miss bandwidth penalty. It also involves a different reliability trade-off because the ECC-related storage is being used to carry tag information.

Neither design makes tag checking free. AmpereOne’s co-located tags can reduce one class of cache and coherence cost, but its store pipeline still has to interact with MTE. Pixel’s reference-like organization can make tag fetches more visible on misses, but not every Pixel workload suffers a major regression. The interface tells software that a comparison occurs; the storage design shapes how much of the comparison competes with the rest of the machine.

Apple’s M5 adds a third data point through Memory Integrity Enforcement, but the study’s analysis is preliminary. It measures SYNC performance and does not offer the same microarchitectural explanation for M5. That limitation is important: a low or high M5 result can extend the comparison set, but it cannot be used to infer the full internal design from the available evidence.

flowchart LR N01["Load or store"] --> N02["Data request"] N01 --> N03["Tag request"] N02 --> N04["Cache and memory path"] N03 --> N04 N04 --> N05{"Core-specific bottleneck"} N05 --> N06["SYNC store ordering"] N05 --> N07["Big-core in-flight checks"] N05 --> N08["Ampere forwarding"] N06 --> N09["Measured slowdown"] N07 --> N09 N08 --> N09 N09 --> N10["Implementation choice or fix"]

The diagram separates the shared obligation from the local failure surface.