[Mlir-commits] [mlir] [MLIR][XeVM] XeVM to LLVM: Update xevm.truncf handling (PR #194491)

Sang Ik Lee llvmlistbot at llvm.org
Fri May 1 08:32:42 PDT 2026


================
@@ -1129,51 +1129,165 @@ class TruncfToOCLPattern : public OpConversionPattern<TruncfOp> {
     // Supported source and result types are resticted for now.
     auto srcEtype = op.getSrcEtype().getEtype();
     auto dstEtype = op.getDstEtype().getEtype();
-    if (auto vecSrcTy = dyn_cast<VectorType>(op.getSrc().getType())) {
-      if (vecSrcTy.getNumElements() != 16)
-        return rewriter.notifyMatchFailure(
-            op, "Only vector src of 16 elements is supported");
-    } else {
+    // Currently only 16 input elements are supported as
+    //  - Any vector beyond 16 elements not a valid OpenCL vector.
+    //  - 2D block load can only load up to 16 16bit elements per lane.
----------------
silee2 wrote:

This pass is XeVM for OpenCL or SPIR-V backend.
Vector type is restricted 16 elements.
As you pointed out, there could be a 32x load by using array_len.
But such load needs to be followed by a shufflevector that splits the load to at most 16 element vector.
FYI, XeVM to LLVM pass has a dedicate pattern to legalize these large load and split them to smaller ones.
So `truncf` will not see any source with more than 16 elements.
Also, regular/normal loads cannot to 32 element load as the return type is still restricted by the max 16 element restriction.  

https://github.com/llvm/llvm-project/pull/194491


More information about the Mlir-commits mailing list