Skip to content

Conversation

@sweiglbosker
Copy link
Contributor

I noticed this because of #159738, though it was only caught by his fuzzer because it wrapped to 0.
Also, is there a reason for the usage of unsigned for sizes in spirv types? I believe most of the builtin types use int64_t for sizes, so it may make sense to do the same for spirv.

@llvmbot
Copy link
Member

llvmbot commented Dec 6, 2025

@llvm/pr-subscribers-mlir-spirv

Author: Stefan Weigl-Bosker (sweiglbosker)

Changes

I noticed this because of #159738, though it was only caught by his fuzzer because it wrapped to 0.
Also, is there a reason for the usage of unsigned for sizes in spirv types? I believe most of the builtin types use int64_t for sizes, so it may make sense to do the same for spirv.


Full diff: https://github.com/llvm/llvm-project/pull/171002.diff

1 Files Affected:

  • (modified) mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp (+5)
diff --git a/mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp b/mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp
index cb9b7f6ec2fd2..f07307fcd2f9d 100644
--- a/mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp
+++ b/mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp
@@ -502,6 +502,11 @@ static Type convertTensorType(const spirv::TargetEnv &targetEnv,
                << type << " illegal: cannot handle zero-element tensors\n");
     return nullptr;
   }
+  if (arrayElemCount > std::numeric_limits<unsigned>::max()) {
+    LLVM_DEBUG(llvm::dbgs()
+               << type << " illegal: cannot fit tensor into target type\n");
+    return nullptr;
+  }
 
   Type arrayElemType = convertScalarType(targetEnv, options, scalarType);
   if (!arrayElemType)

@llvmbot
Copy link
Member

llvmbot commented Dec 6, 2025

@llvm/pr-subscribers-mlir

Author: Stefan Weigl-Bosker (sweiglbosker)

Changes

I noticed this because of #159738, though it was only caught by his fuzzer because it wrapped to 0.
Also, is there a reason for the usage of unsigned for sizes in spirv types? I believe most of the builtin types use int64_t for sizes, so it may make sense to do the same for spirv.


Full diff: https://github.com/llvm/llvm-project/pull/171002.diff

1 Files Affected:

  • (modified) mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp (+5)
diff --git a/mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp b/mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp
index cb9b7f6ec2fd2..f07307fcd2f9d 100644
--- a/mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp
+++ b/mlir/lib/Dialect/SPIRV/Transforms/SPIRVConversion.cpp
@@ -502,6 +502,11 @@ static Type convertTensorType(const spirv::TargetEnv &targetEnv,
                << type << " illegal: cannot handle zero-element tensors\n");
     return nullptr;
   }
+  if (arrayElemCount > std::numeric_limits<unsigned>::max()) {
+    LLVM_DEBUG(llvm::dbgs()
+               << type << " illegal: cannot fit tensor into target type\n");
+    return nullptr;
+  }
 
   Type arrayElemType = convertScalarType(targetEnv, options, scalarType);
   if (!arrayElemType)

Copy link
Member

@kuhar kuhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing this. Would it be possible to add a lit test?

@sweiglbosker
Copy link
Contributor Author

Thanks for fixing this. Would it be possible to add a lit test?

Done!

@kuhar kuhar merged commit 4709018 into llvm:main Dec 8, 2025
11 checks passed
@sweiglbosker sweiglbosker deleted the spirvconvert branch December 8, 2025 22:11
honeygoyal pushed a commit to honeygoyal/llvm-project that referenced this pull request Dec 9, 2025
…ayType (llvm#171002)

I noticed this because of
llvm#159738, though it was only
caught by his fuzzer because it wrapped to 0.
Also, is there a reason for the usage of `unsigned` for sizes in spirv
types? I believe most of the builtin types use `int64_t` for sizes, so
it may make sense to do the same for spirv.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants