[PATCH] D78541: [MLIR] Ensure `gpu.func` must be inside a `gpu.module`.

[Alex Zinenko via Phabricator via llvm-commits]

ftynse added a comment.

In D78541#1994763 <https://reviews.llvm.org/D78541#1994763>, @mravishankar wrote:

> @ftynse , @herhut is this giving any added semantic advantage? I have been trying to see if there is a way to target `gpu.func` directly without going through `gpu.launch` + outlining. Having the requirement that a `gpu.func` always live in a `gpu.module` seems too restrictive. Just want to understand the advantage apart from the fact that all `gpu.func` need to live in a module "separate" from the host side.


We always had a requirement that `gpu.func`s live in a somehow special module. Originally, it was a module with a `kernel_module` attribute. This is necessary to pick out the modules that should be translated to device-specific dialects. Later, `gpu.module` was introduced, but the old condition with the attribute was not removed. This change basically completes the transition.

I do see some value in having a dedicated `gpu.module` to clearly separate what is intended for device and what is not. Your issue with generating a `gpu.func` without `gpu.launch_func` seems mostly orthogonal: this is a matter of writing the conversion, not of the rules the resulting IR must follow. If you have another conversion pass (or just IR building code) that creates a `gpu.func`, it can equally create a `gpu.module` first. Not having a gpu.module would put the semantics in a weird state when, for example, the same function is called from both gpu.func and from std.func or if there is some global state mutation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78541