[Mlir-commits] [mlir] [mlir][spirv] Add definition for selected sample operations (PR #129558)

Andrea Faulds llvmlistbot at llvm.org
Fri Mar 7 08:24:09 PST 2025


================
@@ -29,10 +31,122 @@ static LogicalResult verifyImageOperands(Operation *imageOp,
                               "follow, as per Image Operands");
   }
 
+  if (spirv::bitEnumContainsAll(attr.getValue(),
+                                spirv::ImageOperands::Lod |
+                                    spirv::ImageOperands::Grad))
+    return imageOp->emitError(
+        "it is invalid to set both the Lod and Grad bits");
+
+  size_t index = 0;
+
+  // The order we process operands is important. In case of multiple argument
+  // taking operands, the arguments are ordered starting with operands having
+  // smaller-numbered bits first.
+  if (spirv::bitEnumContainsAny(attr.getValue(), spirv::ImageOperands::Lod)) {
+    if (!isa<spirv::ExplicitLodOpInterface>(imageOp) &&
+        !isa<spirv::FetchOpInterface>(imageOp))
+      return imageOp->emitError(
+          "Lod is only valid with explicit-lod and fetch instructions");
+
+    if (index + 1 > operands.size())
+      return imageOp->emitError("Lod operand requires 1 argument");
+
+    spirv::ImageType imageType;
+
+    if (isa<mlir::FloatType>(operands[index].getType())) {
+      if (!isa<spirv::SamplingOpInterface>(imageOp))
+        return imageOp->emitError("for sampling operations, Lod must be a "
+                                  "floating-point type scalar");
----------------
andfau-amd wrote:

I don't think this condition fits this error message, and it might produce confusion. This will show up specifically if the operation is *not* a sampling operation. Perhaps you should flip the nesting of the if's, so that you test first if it's a sampling op or a fetch op, then what type is in use.

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


More information about the Mlir-commits mailing list