[Mlir-commits] [mlir] [mlir] Add existing callback functions to GpuModuleToBinary pass (PR #117694)

[Mehdi Amini]

================
@@ -95,7 +95,19 @@ def GpuModuleToBinaryPass
     Option<"cmdOptions", "opts", "std::string", [{""}],
            "Command line options to pass to the tools.">,
     Option<"compilationTarget", "format", "std::string", [{"fatbin"}],
-           "The target representation of the compilation process.">
+           "The target representation of the compilation process.">,
+    Option<"initialLlvmIRCallback", "initialLlvmIRCallback", 
+           "llvm::function_ref<void(llvm::Module &)>", "nullptr",
+           "Callback invoked with the initial LLVM IR for the device module.">,
+    Option<"linkedLlvmIRCallback", "linkedLlvmIRCallback", 
+           "llvm::function_ref<void(llvm::Module &)>", "nullptr",
+           "Callback invoked with LLVM IR for the device module after linking the device libraries.">,
+    Option<"optimizedLlvmIRCallback", "optimizedLlvmIRCallback", 
+           "llvm::function_ref<void(llvm::Module &)>", "nullptr",
+           "Callback invoked with LLVM IR for the device module after LLVM optimizations but before codegen.">,
+    Option<"isaCallback", "isaCallback", 
+           "llvm::function_ref<void(llvm::StringRef)>", "nullptr",
+           "Callback invoked with the target ISA for the device, for example PTX assembly.">
----------------
joker-eph wrote:

Yes that was indeed my concern. 
So in general we just don't expose that kind of things as pass options. Instead we make it so that the pass body is extracted as a utility, and the pass is a very thin wrapper. That way people can build their own pass downstream.

What we could do upstream though is add a "isaCallbackDumpPath" option and use this to let users provide a way to save to a file. That may not be enough for what you want to do, but you can adjust downstream with your own pass.

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