[XPU] Bump xpu-sdnn-objects to v0.3.6.6.1 to fix the int8 dot failure

[hulong02-klx]

An i8 -> f32 conversion in the kernel becomes an arith.sitofp inside a linalg.generic, which TritonSDNNLegalize rewrites into an sdnn.dma cvt and DMAInCvtCombiner then folds into the input-side sdnn.dma in, leaving a single converting i8 -> f32 DMA. That transfer is programmed with cfg_type=0, whose third field is the (de)quantisation scale the engine applies whenever it converts between an integer and a floating-point element type. The old objects left that field at 0, so every element was multiplied by 0.0f: an i8 -3 landed in unisram as -0.0f and a tl.dot fed from that buffer returned all zeros. The float -> int direction was already routed to dma_cfg_data_type_quant; the int -> float dequant direction was not.

v0.3.6.6.1 is v0.3.6.6.0 with only lib/Conversion/TritonSDNNToLLVM/ TritonSDNNToLLVM.cpp.o rebuilt, plus debug info stripped from every object and archive in the tarball (the previous release shipped 788MB of debug_info in libTritonSharedForXPU.a alone), which takes the download from 152MB to 2.9MB. sha256 d54f7d256a4dc244fbcec1c30fb6d3b2a126417567a600f65f87348b82fadabd

Verified on KL3 (xpu3): int8 x int8 -> f32 tl.dot now matches torch.mm, whereas v0.3.6.6.0 mismatches on 99.8% of elements (all-zero output).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ zhzhcookie
❌ HuLong02
_{You have signed the CLA already but the status is still pending? Let us recheck it.}