[PATCH] D74012: [mlir][spirv] Use spv.entry_point_abi in GPU to SPIR-V conversions

Mahesh Ravishankar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 10 10:13:28 PST 2020


mravishankar added a comment.



> Maybe I am missing something here, but from the GPU dialect, the sizes are passed to the `gpu.launch`, so you can take them from there. If you want to specialize a kernel for specific sizes, you need to ensure compatible call sites, like in other function specialization. Is this more about driving upper layers of code generation so that you end up with a `gpu.launch` that has sizes you want? Or do you want to make `gpu.func` usable independent of the `gpu.launch`?

I think you hit upon the core issue here. We would like `gpu.func` usable independent of `gpu.launch`. The way I see it, `gpu.func` allows for arbitrary workgroup size, but for cases where the workgroup size is fixed, the workgroup size is specified as an attribute on the function. For GPU to SPIR-V it is a pre-requisite that the workgroup size be a constant, so the change here makes it a requirement to have `spv.entry_point_abi` attribute on the `gpu.func` for the conversion to succeed (earlier it was implemented by having the workgroup size passed as an argument at pattern construction time). 
Coming to the `gpu.launch` issue, I think we should have `gpu.launch` semantics be that the workgroup size be constant values if the `gpu.func` used has the attribute set. It would actually be better to go a bit further. Make the workgroup size arguments optional. If unspecified, the function uses a constant workgroup size, and would be illegal to specify if the target function has a constant workgroup size. This would be fairly easy to enforce in the verification.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74012





More information about the llvm-commits mailing list