Bottleneck evidence

The classification is an experiment

Arithmetic intensity places the kernel on the roofline; it does not prove which ceiling binds. Intensity is a property of the code, while the binding ceiling also depends on the shape and the rig. That is why the classification is measured. The proof is a perturbation. Change one term and see which way the time moves:

same flops, fewer bytes   (fuse the epilogue)   -> time falls?  memory-bound
same bytes, more flops    (extra FMA per load)  -> time flat?   memory-bound
same work, better ILP     (unroll, rename)      -> time falls?  compute or latency

The first two are the useful pair because they move intensity without changing the answer. If removing a full output traversal leaves the time unchanged, bytes were not the limit, whatever the loop looks like.

Counters, where you have them

On hardware, perf stat gives cycles, instructions, cache and bus events, and the ratio of achieved to peak bandwidth is direct evidence. On QEMU user-mode there is no guest performance monitoring unit and no cache or DRAM model: perf stat on the qemu-riscv64 process measures TCG dispatch and the host, not the guest memory system. Saying so is part of the evidence. On this rig the classification rests on ablations plus a traffic model, and the writeup labels the model as a model. Record the evidence as a table: the term you changed, the direction the time moved, and the conclusion it supports.

Things that break

Classifying from the source is the common failure: three nested loops look compute-heavy and a one-line elementwise op looks memory-bound, and both can be wrong. Running host perf on the emulator and reporting its cache misses is the second. The third is generalising one shape: the classification can move with the shape, and the tile sweep shows where.