xlauko 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.

The origin of pointer dialect is that it started as extracting pointer 
representation from LLVM dialect as it might be usefull for other dialects too. 
See 
[RFC](https://discourse.llvm.org/t/rfc-ptr-dialect-modularizing-ptr-ops-in-the-llvm-dialect/75142).
So as we are ultimatelly lowering to LLVM IR, we should be able to easily map 
to pointer dialect representation.
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?

https://github.com/llvm/llvm-project/pull/161028
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to