Conversion FuncOp from SPIRV To LLVM

I want to convert from spirv::FuncOp to LLVM::FuncOp. with some attributes attached, e.g., kernel or not.

GPUOpsLowering.cpp has a code section to add attribute if it is a kernel (in GPUFuncOpLowering::matchAndRewrite). So doing this itself should not be hard. My question is that if I want to do attach the kernel attribute, do I have to duplicate the code in FuncConversionPattern in a customized ConversionPattern?

It’s just a few lines of code, so duplicating is okay. The FuncConversionPattern is also pulled in via its dedicated entry point mlir::populateSPIRVToLLVMFunctionConversionPatterns so you should be able to subsitatue that with yours.

If you’d like to make it more integrated, depending on what you want to do there. If you need to do some “conversions” over the attribute, we can also consider exposing the FuncConversionPattern in the header file so that you can subclass it and handle the attribute (conversion) before/after calling the base matchAndRewrite. Attributes are relatively free form so I don’t think it will intervene with the base matchAndRewrite typically. Or if you just want to pass things through, we can maybe tech the current pattern to understand pass through attributes better. Though I’d like to see more context and cases to go down these paths.

The context is that there are different shader types/kernel in spirv, e.g., kernel, frag, vertx. In spir-v binary, those information is conveyed in spirv::EntryPointOp. SPIRVToLLVM conversion erases the spirv::EntryPointerOp directly, but the later compilation flow needs those information for different reasons, e.g., an Output in a fragment shader have a different codegen comparing to it in a vertex shader. This is why we want to attach the shader/kernel type as an attribute in llvm::FuncOp.

Having a separated function sounds good to me, especially we are still experimenting those conversions. I just asked to check whether there is any approach I don’t know. Thank you for your reply!

Thanks for the explanation! That makes sense. It’s actually a compelling use case (different graphical pipeline stages) to have more integrated support.

It’s very much due to the fact that the early prototyping only focuses on compute use cases, which means only compute shader needs to be supported so we can basically ignore it. Please don’t anchor too much on this. We can figure out better ways to handle entry point ops for graphics use cases, depending on how your SPIR-V consumer expects.

No problem. Please feel free to reach out again once you think you’ve reached some stability and would wanting to merge or let the upstream support your use cases better!