[PATCH] D72336: [mlir] Create a gpu.module operation for the GPU Dialect.

Stephan Herhut via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 8 02:24:57 PST 2020


herhut added a comment.

Thanks for adding more structure! This needs a little more work on the description but otherwise looks good to me.



================
Comment at: mlir/include/mlir/Dialect/GPU/GPUOps.td:597
+    single region with a single block. This block is expected to contain
+    operations that define a symbol. GPU modules are required to have a name
+    that is used for symbol resolution by the gpu.launch_func operation.
----------------
antiagainst wrote:
> It's a bit confusing for me here saying that `gpu.launch_func` is to launch a `gpu.module`... I'd expect a module to contain some entry functions that a `gpu.launch_func` can launch. Seems like we either need to have a `gpu.launch_module` to be consistent, which needs to define the semantics first for sure... Maybe consider revising the wording here at least?
I think the underlying problem is that we have no notion of qualified symbols implemented in MLIR yet. So the launch_func actually gets a module and function. I agree the description is misleading.


================
Comment at: mlir/lib/Dialect/GPU/IR/GPUDialect.cpp:822
+  OperationState state(loc, getOperationName());
+  Builder builder(loc->getContext());
+  GpuModuleOp::build(&builder, state, name);
----------------
rriddle wrote:
> Why is this method necessary?
It is the equivalent of ModuleOp::create and FuncOp::create to allow creation of modules outside the context of a surrounding module. We could refactor the code here to use a builder, as the module is inserted into a surrounding module but in general that might not be the case. Or is there a way to have create methods generated?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72336/new/

https://reviews.llvm.org/D72336





More information about the llvm-commits mailing list