[Feature Request] Refactor Kernel Cache System for Multiple Backends

[LeiWang1999]

Current Situation:
The kernel cache system in Tilelang currently resides in tilelang/cache/kernel_cache.py and uses a series of if-else statements to handle caching for various backends (CUDA, HIP, Metal, CuteDSL, etc.). This approach has become increasingly problematic as we add more backends.

We should refactor and create a maintainable, scalable kernel cache system that can easily accommodate current and future backends without requiring modifications to core cache logic.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• [Feature Request] Include compilation args as part of the kernel cache's hash key #891
• [Feature Request][CI] Enable ccache or sccache for cibuildwheel for manylinux #1155
• [BUG] Autotuner uses cache results for different input shapes #1250

🔗 Related PRs

#1315 - [Bugfix] Fix autotune cache [merged]
#1460 - [Cache] Rename sparse compress cache directory [merged]

👤 Suggested Assignees

• LeiWang1999
• Rachmanino
• XuehaiPan
• SiriusNEO

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[SiriusNEO]

@silentCoder-dev @LeiWang1999 We can move away from if-else chains and adopt a Base Class + Subclass design:

• Unified Interface: Define an abstract BaseKernelCache class that standardizes methods like get, put, and compile.
• Backend Implementation: Implement specific subclasses for each backend (e.g., CUDAKernelCache, HIPKernelCache, MetalKernelCache) to handle their specific logic.
• Dispatch: Use a factory or registry mechanism to instantiate the correct cache class based on the target.

This decouples the core logic from backend specifics, making the system scalable and easier to maintain when adding new backends. And we should also carefully think the difference between different execution_backend and target, which are two different concepts.