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

[Mehdi Amini]

================
@@ -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);
----------------
joker-eph 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"

Sure, but that's not really helping me reasoning here: I see this as completely anecdotical actually.

> 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.

Why strange? That seems to be what I expect from anyone targeting the GPU dialect actually?



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