fabianmcg wrote: > I've seen there was a lot of updates of the dialect recently, so I am > uncertain about how mature the things are. Maybe @fabianmcg or @joker-eph > might have better insight?
I'll answer in reverse order, it's not yet mature. I expect it to be mature by the end of the year though. However, I would recommend the adoption of `PtrLikeTypeInterface` now. I do plan to push `MemorySpaceAttrInterface` adoption into more memory space attributes, for example, GPU address spaces, etc.... However, that's just for interacting with the pointer dialect and its operations. Therefore, the only case `cir` would benefit from implementing the interface, is if at some point you want to convert `cir` ops to `ptr`, but preserve `cir` memory space semantics. That is something like: ```mlir %v = ptr.load %ptr : !ptr.ptr<#cir.memory_space<f32>> -> f32 ``` > I see that there's an LLVM `AddressSpaceAddr` that uses the > `MemorySpaceAttrInterface` but I only see this attribute attached to > `ptr.ptr` in tests in the form `!ptr.ptr<#llvm.address_space<0>>`. If I'm > reading this correctly, that's defining an opaque pointer in address space > zero. This looks like what we're doing with `target<n>` address spaces. The original plan is to eventually remove `!llvm.ptr<n>` in favor of `!ptr.ptr<#llvm.address_space<n>>`, but, that transition is not happening soon. Also, the plan is to make the transition almost invisible to users of the type. But it would mean that in the end `cir` would end up converting to `!ptr.ptr` under the hood. > But I also see that the GPU and AMDGPU dialects have their own address space > attributes which look a bit closer to what we're doing currently with > "language" address spaces. It's not clear to me how we'd transition from CIR > to these. GPU has an enum defining `global`, `workgroup`, and `private`. We > have `global` and `private` but it's not clear to me which of our other > options would map to `workgroup`. For AMDGPU there are `fat_raw_biffer`, > `buffer_src`, and `fat_structured_buffer`. I don't even have a guess there. The type converter can handle that conversion. For example, the `#gpu.address_space<global>` memory space will get converted to `1` on conversion to LLVM: ``` @kernel_1(%arg0 : memref<f32, #gpu.address_space<global>>) // After signature conversion @kernel_1 (%arg0: !llvm.ptr<1>, %arg1: !llvm.ptr<1>, %arg2: i64) ``` So, it's perfectly doable to convert some of the memory spaces in `cir` to `gpu` memory spaces. https://github.com/llvm/llvm-project/pull/161028 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
