andykaylor wrote: > @bcardosolopes @andykaylor In general it might be worthwhile to align more > with `ptr` dialect and its modeling of address spaces. Maybe even use > `MemorySpaceAttrInterface` directly in out pointer type
I definitely like the idea of aligning better with other dialects, but it's not clear to me what that would mean. A few minutes browsing various in-tree dialects left me confused. 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. 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. https://github.com/llvm/llvm-project/pull/161028 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
