# \[RFC\] \`address\` dialect

**URL:** <https://discourse.llvm.org/t/rfc-address-dialect/74937>\
**Category:** MLIR\
**Created:** [November 14, 2023, 9:28pm UTC](https://discourse.llvm.org/t/rfc-address-dialect/74937 "2023-11-14T21:28:13Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![fabianmc](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/fabianmc/32/21079_2.png) [@fabianmc](https://discourse.llvm.org/u/fabianmc)\
**Post date:** [November 15, 2023, 1:59pm UTC](https://discourse.llvm.org/t/rfc-address-dialect/74937/14 "2023-11-15T13:59:57Z")

</div>

> [@mehdi\_amini](#):
>
> Not necessarily, this is something on my TODO list for a while actually, we just need an attribute interface for the translation. This can be something that takes a TargetTriple during the translation as well.

**There’s a pretty simple solution, let’s make `!llvm.ptr` a builtin type (`ptr`) capable of supporting any address space attribute**, then there would be no need for the `address` type. However, we’d still need a dialect to interact with it.

One more reason to not want `!llvm.ptr` in higher representations is the need to link to `LLVMDialect`.

> [@mehdi\_amini](#):
>
> > [@fabianmc](#):
> >
> > Also, semantically, an `address` might be more than a traditional LLVM pointer; for example, it could be a fat pointer with an underlying struct representation.
> 
> This is the part that isn’t clear to me, do you have example? How does this play with `cast_int` and `ptradd`?

A disclaimer, both `cast_int` & `ptradd` would need special lowerings via user supplied patterns or an interface attached to the address space for them to work with fat pointers, and `cast_int` might not be semantically valid for all address spaces.

One simple example is an always de-allocatable pointer:

```C++
struct FatPtr {
  int8_t *allocatedPtr;
  int8_t *ptr;
};

```

in this case:

```C++
cast_int(myFatPtr) == static_cast<intptr_t>(myFatPtr.ptr)
ptradd(myFatPtr, indx) == FatPtr(myFatPtr.allocatedPtr, myFatPtr.ptr + indx)

```

A more complex example with HW support is: [Representing buffer descriptors in the AMDGPU target - call for suggestions](https://discourse.llvm.org/t/representing-buffer-descriptors-in-the-amdgpu-target-call-for-suggestions/68798/1)

> [@mehdi\_amini](#):
>
> 1. it assumes a specific representation of the memref

`from_memref` & `to_memref` only assume that `memref`’s have two pointers (can be the same), the actual representation of the `memref` is only known until it’s lowered.

> [@mehdi\_amini](#):
>
> it’s not clear to me what you do with the pointer to the data alone without the memref metadata in general?

In the presence of multiple `memref`s there might be redundant metadata, see the example at the end [[RFC] `address` dialect - #11 by fabianmc](https://discourse.llvm.org/t/rfc-address-dialect/74937/11). In that example the kernel signature went from 21 arguments to 6 arguments by using `address`, and the `memref`s can be reconstructed for computation inside the kernel.

It’d be even possible to add an attribute to the function specifying redundant metadata, and a pass making the transformation.

> [@mehdi\_amini](#):
>
> This also seems to overlap with `memref.extract_aligned_pointer_as_index`, but then the RFC isn’t really explaining all this.

That op could be potentially removed, also, there’s no guarantees `index` can support the pointer.

---

_[View the full topic](https://discourse.llvm.org/t/rfc-address-dialect/74937)._