Design check: Intel Arc (SYCL) backend

I am evaluating adding a fourth backend targeting Intel GPUs (Arc dGPUs, Xe iGPUs) via SYCL / oneAPI, and want a maintainer signal before investing further.

Approach

- Mirror the CUDA layout: a new in-tree candle-sycl-kernels crate holding kernel sources bootstrapped by running Intel's SYCLomatic over candle-kernels/*.cu, then hand-fixed. build.rs AOT-compiles them with icpx -fsycl, same shape as
candle-flash-attn/build.rs drives nvcc.
- candle-sycl-kernels is excluded from the workspace (like candle-kernels and candle-metal-kernels), so a plain cargo build never invokes icpx and never needs oneAPI installed.
- Everything behind #[cfg(feature = "sycl")]: no new enum variants, no new trait methods, and no dependency changes for default builds.
- Small in-tree host-side FFI layer rather than a dependency on any of the (currently very new) SYCL binding crates on crates.io.
- GPU-free CI job that type-checks the sycl feature.

A compiling skeleton with these properties is working locally, and the Arc device enumerates fine (via the intel/oneapi-basekit container). I am also aware of the effort for the ROCm backend in #3801 and willing to share the common "N-th backend" plumbing if that's the correct approach.

Question

Is an icpx / oneAPI build-time dependency (isolated as above, only when --features sycl) acceptable for something you'd be willing to merge and maintain? If not, is there a form you'd prefer — e.g. prebuilt SPIR-V shipped in-tree, or
runtime JIT instead of AOT?

Start by reviewing candle-kernels/*.cu, candle-flash-attn/build.rs, and the proposed candle-sycl-kernels crate layout, then compare the ROCm backend effort in #3801. The immediate outcome is maintainer guidance on whether an isolated icpx/oneAPI build-time dependency is acceptable and what implementation form could be maintained.

Written by the indexing model from the issue text.