sycl: contiguous fast path + 32-bit index math for unary elementwise ops

[Titaniumtown]

Overview

Every op routed through ggml_sycl_op_unary (silu, sigmoid, gelu*, exp, softplus, ETC) ran a generic strided kernel doing three int64 div/mod per element to reconstruct 4-D indices.

Intel's Xe cores has no native 64-bit integer divide op. So when compiling the kernels, ICPX adds its own implementation. The extra index math then dominates the kernel's compute time: SILU measured 3.2 ms/call on {2048,17408} f32 activations vs a ~0.63 ms bandwidth floor. This path is called 96x per qwen 3.6 ubatch, which results in 13% of profiled op time during prefill.

But, when src0 and dst are both contiguous, we can skip the index reconstruction as the reconstruction of indices is wasteful compute-wise when it can be easily calculated.

So what I ended up doing is adding a fast path that allows the skipping of those very very performance heavy division and 4-D index reconstruction operations.

Additional information

Benchmarks on an Arc B70 Pro

llama-bench -m Qwen3.6-27B-UD-Q4_K_XL.gguf -ngl 999 -fa 1-ctk q8_0 -ctv q8_0 -p 512,2048 -n 128 -r 4

master @ 571d0d5:

| model                          |       size |     params | backend    | ngl | type_k | type_v | fa |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | -----: | -----: | -: | --------------: | -------------------: |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |           pp512 |        726.59 ± 2.11 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |          pp2048 |        692.99 ± 2.15 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |           tg128 |         22.95 ± 0.05 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |           pp512 |        722.04 ± 2.21 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |          pp2048 |        688.11 ± 1.73 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |           tg128 |         22.86 ± 0.02 |

This PR:

| model                          |       size |     params | backend    | ngl | type_k | type_v | fa |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | -----: | -----: | -: | --------------: | -------------------: |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |           pp512 |        755.04 ± 6.19 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |          pp2048 |        718.86 ± 1.67 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |           tg128 |         22.87 ± 0.30 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |           pp512 |        756.55 ± 3.36 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |          pp2048 |        716.64 ± 2.40 |
| qwen35 27B Q4_K - Medium       |  16.67 GiB |    27.32 B | SYCL       | 999 |   q8_0 |   q8_0 |  1 |           tg128 |         23.09 ± 0.04 |

TL;DR 4.3-3.9% uplift on pp bandwidth with no effect on decode.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES - Used Opus 4.8 to help me understand codebase and profile the codebase along with understanding various terminology.

[arthw]

It's good job!

With Qwen3.6-27B-UD-Q4_K_XL.gguf on B60:

Test	fa	Base t/s	Primary t/s	Increase Rate (Primary vs Base)
pp512	0	186.00	189.34	1.80%
pp512	1	184.17	187.44	1.78%
tg128	0	16.91	16.99	0.47%
tg128	1	16.90	17.00	0.59%

Thank you!

[arthw]

@Titaniumtown
After you feel the PR is ready review, please change the status from "Draft" to "Open"

[Titaniumtown]

@arthw There is a limit for the # of non-draft PRs I can have open. I can have only one according to Github. I have to wait for #25903 to be merged to make this one "Open".

[arthw]

Ok, no problem!

[mndodd]

Have you considered using common.hpp:fast_div_modulo()? Could be another half-percent for you to grab if my test of your approach applied to gated_op_fused_swiglu() is good metric.

test	mode 0 i64 (base)	mode 1 i32 (#25946)	mode 2 fastdiv	Δ(2 vs 1)	Δ(2 vs 0)
pp512	875.42 ±3.55	872.67 ±10.03¹	882.48 ±2.47	+1.12%	+0.81%
pp2048	870.87 ±1.01	870.97 ±1.59	875.25 ±0.77	+0.49%	+0.50%
tg128	16.84	16.84	16.84	+0.02%	+0.02%

¹ mode1 pp512 sd inflated by one 848 t/s rep in block 2 (DVFS blip); its other 7 samples ≈ 876.

[Titaniumtown]

@mndodd Cool find! I don't have the time in the next few days to do this, but I will definitely check this out when I can.

[arthw]

@Titaniumtown
Could you change the status of this PR from draft to open if you think it's ready to review and merge?

Thank you!

[Titaniumtown]

@mndodd Thanks for the suggestion, I added this!

[Titaniumtown]

Ready for review!