fla-dispatch-backends

Create a BaseBackend subclass under the operation's backends/ package, set backend_type, package_name, env_var, default_enable, and priority, then implement the verifier and backend function. Register it in the operation's backends/__init__.py and add dispatch tests.

The @dispatch decorator tries registered backends sorted by priority, where lower values run first. A backend is used only when both is_available() and is_enabled() return true and its verifier accepts the call; otherwise dispatch falls to the next backend or the default implementation.

Yes, set FLA_DISABLE_BACKEND_DISPATCH=1 to bypass the dispatch decorator entirely and run the original implementation. Individual backends can also be toggled with their own env vars such as FLA_TILELANG or FLA_FLASH_KDA.

Verifiers run on every dispatched call to decide routing, so they must be cheap, deterministic, and free of mutations to registries, tensors, RNG state, or environment variables. Side effects would corrupt fallback behavior and break torch.compile-friendly dispatch.

The dispatch wrapper is marked with torch.compiler.disable, so backend selection happens outside compiled graphs. Keep selection logic in the wrapper and put compilable work inside the selected backend implementation, checking is_available and is_enabled directly rather than cached can_use paths.