[RFC] `address` dialect

[fabianmc]

@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:

struct FatPtr {
  int8_t *allocatedPtr;
  int8_t *ptr;
};

in this case:

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

@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 memrefs there might be redundant metadata, see the example at the end [RFC] `address` dialect - #11 by fabianmc. In that example the kernel signature went from 21 arguments to 6 arguments by using address, and the memrefs 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.