Multi-DSL/device refactoring

[sandlbn]

• Generalize pipeline from Triton/XPU-only to support multiple DSLs (Triton, Gluon, SYCL, CUDA) and devices (XPU, CUDA, CPU)
• Add DSL and DeviceType enums, abstract DeviceConfig with XPU/CUDA subclasses
• Add DSL-stage compatibility registry (dsl_registry.py)
• Abstract device query module (device_query.py) dispatching XPU/CUDA
• Parameterize LLM prompts by DSL/device (prompts/device_prompts.py)
• Restructure knowledge base: common/, triton/{xpu,cuda}/, gluon/xpu/, sycl/xpu/
• Add --device and --dsl CLI flags
• Add .gitignore

[sandlbn]

This is more like proposal to add other DSLs, we can discuss it in this thread. @danielfleischer @gbenms

[danielfleischer]

The HW and DSL generalization is fine.

Where did the 18 new examples in KB/triton/XPU/ come from? are they synthetic, are they based on KernelBench?

[danielfleischer]

Where did this come from?

[sandlbn]

extracted from sycl tla kernels, I will update this PR for couple new when you pass existing stuff.

[sandlbn]

seems to be working:

     Speedup: 23.09x
     - I changed strategy from “pick one supposedly better tile” to a runtime micro-autotuned kernel family while preserving the proven RowMajor/ColumnMajor layout fix and BF16->FP32 math path. This directly addresses the stage issue and avoids locking into a regressing shape. The sweep prioritizes 256x256x32 and 128x128x64, also testing 128x256x32, 256x128x32, and retaining the current 256x128x16 as a fallback/reference. I also hardened reference GEMM stride products to int64. If this still doesn’t be

Total Speedup: 23.10x
Performance: 3.71 → 85.68 TFLOPS
Execution Time: 37.047 ms → 1.604 ms

[danielfleischer]

Is this from KernelBench?

[sandlbn]

it is as example of fully fused kernel

[danielfleischer]

More comments.

[danielfleischer]

Maybe it's a good opportunity to have backend-specific agents in dedicated modules. So all the SYCL is there, TRITON, Gluon, etc.

[danielfleischer]

Good