[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