The RewritePattern will become one of several, and will be part of the LLVM conversion pass (instead of a separate pass following LLVM conversion).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Conversion/GPUCommon/ConvertLaunchFuncToRuntimeCalls.cpp | ||
---|---|---|
323 | Oops. I'm looking into this now. |
mlir/lib/Conversion/GPUCommon/ConvertLaunchFuncToRuntimeCalls.cpp | ||
---|---|---|
89 | What is the advantage of having these as field vs. a local helper function? | |
159–160 | This is dangerous, as the module could be deleted before the global has been created. Also, it is not strictly required as part of the lowering as long as we mark the nested gpu module as legal. It only needs to cleaned away shortly before exporting the module to llvm and that can be done by just traversing the outer module. | |
213 | This alignment seems odd. Not you doing but 0 would be canonical. | |
324 | Please use the rewriter instead, | |
357 | Would launchOp.getNumKernelOperands()work here, as well? It would avoid the search for the kernel. |
Thank you very much Stephan for the review.
mlir/lib/Conversion/GPUCommon/ConvertLaunchFuncToRuntimeCalls.cpp | ||
---|---|---|
89 | It doesn't make a big difference. Having a FunctionCallBuilder class maybe separates the details a little from the rest of the ConversionPattern. And probably overall it's a little shorter. But I can certainly change it, if you prefer functions. | |
159–160 | I don't think it's dangerous as long as the ConvertLaunchFuncOpToGpuRuntimeCallPattern does not run after EraseGpuModuleOpPattern. In the same pass is OK, and the populateGpuToLLVMConversionPatterns function makes sure they are always part of the same PatternsList. Why would you like to not clean up the gpu modules when they are no longer needed, but have the user to do this manually? Doesn't populateGpuToLLVMConversionPatterns imply that it removes all gpu ops, instead of leaving one particular op type without uses? | |
213 | Changed to 0. | |
324 | Done, but I did not change the builder type in the other functions. Should I? | |
357 | I don't think so because that would give you the non-flattened number of arguments, right? |
mlir/lib/Conversion/GPUCommon/ConvertLaunchFuncToRuntimeCalls.cpp | ||
---|---|---|
159–160 | But how do you guarantee this? If the kernel module is before the functions that contain the launch, then it might get removed already, no? | |
324 | I cannot see that change. No need to change type as long as it is backed by the rewriter for the pattern. Otherwise the rollback would not work. | |
357 | Good point, thanks! |
mlir/lib/Conversion/GPUCommon/ConvertLaunchFuncToRuntimeCalls.cpp | ||
---|---|---|
159–160 | I verified that it does not matter whether the kernel module is before the function or after. rewriter.erase() only marks it for removal, the actual removal happens during the pass' finalize(). So the kernel module will always be available for the gpu.launch_func rewrite in the same pass. | |
324 | Yes, it's backed by the rewriter. You don't see the change because I haven't pushed it. It's always a bit of a dance and I wanted to wait for the other things to get resolved. |
mlir/lib/Conversion/GPUCommon/ConvertLaunchFuncToRuntimeCalls.cpp | ||
---|---|---|
159–160 | Ah, ok, thanks for checking. In that case this is fine of course. |
What is the advantage of having these as field vs. a local helper function?