Thanks for your feedback so far everyone!
The initial intention of this work was to enable people to target SPIR-V devices through the LLVM dialect and the LLVM SPIR-V backend. We believe there is valid reasons for users to use this route, e.g., to re-use existing lowerings to LLVM dialect for other backends (as is the case for Triton) or to integrate with other frontends using LLVM IR directly (e.g., OpenCL), and it seems there is interest in general in this route.
This should however not be a replacement of the SPIR-V dialect, just an alternative, so we re-designed GEN to also provide lowerings to SPIR-V when concerns about the parity with SPIR-V dialect were raised earlier in the discussion.
I agree that this leads to some duplication with the GPU-to-SPIRV lowering for the operations added to GEN in the first PR. This is probably an artifact of those operations being rather generic and not Intel GPU specific. We should probably distinguish these generic operations from more Intel GPU-specific operations that we may add in future steps.
For these generic operations, there are multiple options on how to handle their lowering (which does not yet exist) to LLVM dialect, targeting the LLVM SPIR-V backend.
-
Keep them in the GEN dialect, provide lowerings to LLVM and SPIR-V and accept the duplication
-
Keep them in the GEN dialect, but only provide lowerings to LLVM for these operations, as GPU-to-SPIRV can be reused for these. Future Intel GPU-specific operations added to GEN would still provide lowerings to LLVM and SPIR-V to keep feature parity of the SPIR-V dialect.
-
Not put those operations in any dialect at all. Instead, provide a lowering from GPU to LLVM, targeting the LLVM SPIR-V backend, as a pass that creates LLVM intrinsic calls.
-
Separate these generic operations out into a dialect akin ROCDL/NVVM and provide lowerings from GPU to that and to LLVM intrinsics,similar to what is done for ROCDL/NVVM. The name of such a dialect would still need to be decided. Future Intel GPU-specific operations could still be put into the GEN dialect with lowerings to LLVM and SPIR-V.
We would be interested to hear your opinions on which of those options you would prefer (or something else entirely). If we find consensus, we would be ready to implement and upstream such consensus.
From our point of view, this additional route to SPIR-V via LLVM would be a valuable addition to the MLIR ecosystem if we find consensus.