[Mlir-commits] [mlir] [mlir][gpu] GPUToROCDL: Add C++ argument to populate allowedDialects (PR #157402)

[Krzysztof Drewniak]

krzysz00 wrote:

> I think the question behind the question is: what can you do with this pass that you can't do with convert-to-llvm and what would it take to make it possible to do with convert-to-llvm?

1. The pass loads in target-specific patterns - `amdgpu-to-rocdl` and the `gpu` to `rocdl` patterns themselves. Those could _maybe_ be run before general convert-to-llvm, but they depend on the LLVM conversion infrastructure. *However*, the AMDGPU dialect to ROCDL dialect conversions add entries to the LLVM type converter (for pointer address spaces attributes), and so those would want to be run at the same time as the rest of the LLVM conversion patterns ... which there's no mechanism for with convert-to-llvm
2. This pass sets up other address space handling. There's a call to `populateGpuMemorySpaceAttributeConversions` in here, which maps memory spaces like `#gpu.address_space<workgroup>` to their correct platform-specific values. There's no generic mechanism that I know of for populating that mapping in a `convert-to-llvm` usage.
3. There's the section that starts
    ```
    // Manually rewrite known block size attributes so the LLVMIR translation
    // infrastructure can pick them up.
   ```
   which compensates for limitations of the gpu-to-llvm rewrites being generic.

In short, convert-gpu-to-rocdl is a pass that does a bunch of non-trivial target-specific setup (and, in one case, post-processing, though maybe that's a bit of a hack) work and adds extra conversion patterns so that we're converting to *AMDGPU* LLVM, not generic LLVM.

If `convert-to-llvm` were set up in a way that would let us put this sort of setup on some entity in the context (ex. a target attribute) and that were plumbed through reliably, we wouldn't need this patt. For now, we do.

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