Review checklist — verifying GPU code

A reviewer (human or LLM) verifying a Miri GPU change should answer these six questions in order. If any answer is "no" or "not visible", the change needs work.

1. Residency. Does every GPU-touching binding start with gpu let / gpu var? Does every kernel capture refer to a device-resident binding or a captured host scalar? Does every gpu fn parameter type implement Accelerable?
2. Cost classes in order. List the cost events (upload, launch, fence + readback). Does the order match the source top-to-bottom? Are there any unexpected fences beyond a cross-residency assignment or .slice?
3. Buffer reuse. Do adjacent kernels over the same gpu var share the buffer (no cross-residency assignment between them)? Is there any let h = g; …; some_kernel(g) where the readback is wasted?
4. Mutability. Is every captured gpu var element written by exactly one thread? Concurrent writes to a non-Atomic element are a compile error — scatter patterns need Atomic buffers. Is every shared write followed by a kernel.barrier() before another thread reads it?
5. Bounds + indexing. Does every in-kernel arr[i] have a visible bounds guard when the index isn't bounded by the iteration range? In host code, are all element reads of device-resident bindings either compiler-rejected or bulk-copied first?
6. Portability. Does the change rely on 64-bit scalars, subgroup ops, or another gated feature? If so, is each one necessary, and is the requirement stated near the kernel?