[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