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

[Igor Wodiany]

================
@@ -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");
----------------
IgWod-IMG wrote:

Yes, you're right. I'll flip the nesting. Regarding the second point, an operation can be neither sampling nor fetch, but the check on lines 46-47 would already filter this out.

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