[Mlir-commits] [mlir] [mlir] Let GPU ID bounds work on any FunctionOpInterfaces (PR #95166)

Krzysztof Drewniak llvmlistbot at llvm.org
Tue Jun 11 14:38:14 PDT 2024


================
@@ -73,12 +85,16 @@ static std::optional<uint64_t> getKnownLaunchDim(Op op, LaunchDims type) {
       return value.getZExtValue();
   }
 
-  if (auto func = op->template getParentOfType<GPUFuncOp>()) {
+  if (auto func = op->template getParentOfType<FunctionOpInterface>()) {
     switch (type) {
     case LaunchDims::Block:
-      return llvm::transformOptional(func.getKnownBlockSize(dim), zext);
+      return llvm::transformOptional(
+          getKnownLaunchAttr(func, GPUFuncOp::getKnownBlockSizeAttrName(), dim),
+          zext);
     case LaunchDims::Grid:
-      return llvm::transformOptional(func.getKnownGridSize(dim), zext);
+      return llvm::transformOptional(
+          getKnownLaunchAttr(func, GPUFuncOp::getKnownGridSizeAttrName(), dim),
+          zext);
----------------
krzysz00 wrote:

I've found at least one downstream context (IREE, where I want to use `-int-range-optimizations`) that has decided the answer is "no" (and even in rocMLIR, we keep our GPU-specific code in a `func.func` until relatively late in our pipeline).

To try and cook up an argument for no, I'd say that GPU-specific code can arise from some notional `-specialize-to-target` pass that takes a `func.func` (or some other `*.func`) and makes clones of it for different targets. Forcing such a pass to change the function operation (and, worse, the nesting structure, because a gpu.func must be in a gpu.module, which is isolated from above, so you'd have to copy any referenced globals in etc) just to get access to `gpu.thread_id` seems to be to be a rather strange decision.

That is, the state of the world is "upstream MLIR provides a GPU compilation infrastructure that's intended to be used as a whole, including gpu.module/gpu.func. However, the wrappers around GPU primitives (like gpu.thread_id or the matrix ops) can be used independently of that infrastructure"

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


More information about the Mlir-commits mailing list