cutile-autotuning

To add autotuning to a CuTile kernel safely, classify it via a decision tree to build a ≤30-config search space, then implement a tune-once/cache/launch wrapper with a DISABLE_AUTOTUNE fallback. Apply split-buffer safeguards for in-place kernels to prevent data corruption.

The exhaustive_search workflow for GPU kernel optimization runs trial configurations once to find the best performance, then caches that tuned kernel for fast repeated launches. This tune-once/cache/launch pattern avoids slow or incorrect performance tuning overhead during execution.

To prevent data corruption when autotuning in-place kernels, apply the split-buffer strategy during exhaustive_search. This safeguard isolates trial runs to avoid overwriting input data across multiple configuration tests.

Use occupancy-only tuning for memory or bandwidth-bound kernels, and use full tile searches for compute-bound kernels. This architecture-aware approach ensures the search space targets the correct performance bottleneck for your specific workload.

Yes, you can bypass autotuning for CI and profiling determinism by setting DISABLE_AUTOTUNE=1. This fallback skips the exhaustive_search workflow, ensuring deterministic kernel execution by avoiding dynamic configuration selection.

CuTile autotuning fails with empty search spaces or compilation timeouts due to unoptimized configuration sets. Guardrails prevent these pitfalls by ensuring a ≤30-config search space and avoiding replace_hints on the hot path to maintain compilation stability.