[RFC] `address` dialect

[mehdi_amini]

@stellaraccident

One reason that I can think of is that it is monolithic, combining a lot of unrelated concepts.

That’s fair, and I’d love to actually split the LLVM dialect into its individual components (pointer and pointer manipulation and concept, arithmetic, and structure/aggregate manipulation, etc.). The LLVM dialect would benefit being organized as a collection of such: LLVM is monolithic by construction, but the independent concepts still exists inside LLVM IR.
We’re already splitting the LLVM “target” with the LLVMTranslationInterface used by NVVM and others actually, this wouldn’t be a very disruptive change I believe (other than dialect prefix in the textual format).

@stellaraccident

Also, your argument against redundancy could easily be flipped to ask why not just use the spirv types and ops everywhere

I wouldn’t be against using a spirv concept if it was relevant, but it turns out that SPIRV types/operations exists to be restrictive and specific to a semantics that does not generalize. What stuck me here is that since LLVM moved to “typeless” pointers, the pointer proposal here looks awfully just like the LLVM pointer (it’s not surprising since LLVM pointers and pointer arithmetic is not far from the purest form you can design I suspect).

[stellaraccident]

@mehdi_amini

That’s fair, and I’d love to actually split the LLVM dialect into its individual components (pointer and pointer manipulation and concept, arithmetic, and structure/aggregate manipulation, etc.). The LLVM dialect would benefit being organized as a collection of such

To my thinking, this is actually the strongest reason to not add an address dialect right now. If the path is to modularize llvm, then it will immediately make little sense in that world, and we’ll soon be having the same manner of debate that we’re currently having with arith.

[fabianmc]

@mehdi_amini

Is this still “a pointer” though? Why wouldn’t this it’s own thing, like memref?

That’s debatable and it could be argued that those kind of ptrs are neither ptr nor memrefs. However, people have modeled fat pointers as pointers in specific address spaces for a while, see for example this CHERI presentation.

@mehdi_amini

You only show one way, not the round-trip.

In that case, there’s no round trip and I’d consider that part of the semantics of the address space.

@stellaraccident

I think there was a time that we kind of implicitly organized things the other way and only used the llvm dialect as the end point of (some) mlir lowering flows which were exiting to “llvm proper.” This may have been more a remnant of the standard dialect days. I don’t think this approach really applies anymore (at least to the same extent), but I don’t think it’s been talked about as a more general vocabulary to draw from. It isn’t surprising to me that there is debate or confusion on this as the thinking of a number of core contributors has evolved on this over the years but I’m not aware of a general discussion on design philosophy.

@stellaraccident is completely right here, my proposal came from a place where the LLVM dialect should be a faithful representation of LLVM IR. I also agree with the idea that type duplication should be avoided, that’s why I later pivoted and proposed making !llvm.ptr a builtin type, there’s no reason it can’t be one.

Having said that, even after the split I think there’s still a need for some of these ops.

Revised proposal

Make !llvm.ptr a builtin-type ptr with a generic attribute address space, and add all 7 ops as the address dialect to interact with the new builtin.ptr type.

Most of the new ops don’t collide with LLVM ops, and the ones that do like cast, cast_int can be merged when the split happens.

[victor-eds]

This looks like some interesting piece of work and has opened some really interesting conversation! Having ptr as a builtin type looks like a great idea and would make sense for many projects such as yours, and ours (SYCL-MLIR, EuroLLVM poster).

We have to +1 allowing any kind of attribute as address space. We also identified this as a lack of abstraction in llvm.ptr. In the SYCL case, we can have four high-level memory spaces: private, local, global and generic. Being SYCL a multi-target programming paradigm, these will be converted to different address spaces depending on the target, so having this bit of abstraction would be ideal. Of course, further restrictions would be added when translating to LLVM IR.

Current dialect looks nice, tho! We are however thinking of two interesting proposals that might be handy for some projects:

• ptrdiff: difference between two pointers
• nullptr: Some targets might not use 0 as a nullptr representation. LLVM IR is lacking this abstraction, but we can have it and assign a value on conversion. This way, e.g., for an AMDGPU target, address.nullptr : ptr<#gpu.address_space<global>> would lower to llvm.mlir.zero and address.nullptr : ptr<#gpu.address_space<workgroup>>, to llvm.mlir.constant 0xFFFFFFFF (see).

We think this is an interest topic and would add value to MLIR, as we can see other projects benefiting from this. It’s always interesting to see other people’s work and how they bring good ideas to the table.

[gysit]

Thanks for the proposal. I think it would be nice to have a dedicated dialect for addressing and the pointer add operation is especially nice.

Can you explain the motivation for the type_offset operation? I would have expect the the size of a type can be determined using the DataLayout dialect? Or do you see a benefit in having the size explicit in IR somehow?

[fabianmc]

@gysit

Can you explain the motivation for the type_offset operation? I would have expect the the size of a type can be determined using the DataLayout dialect? Or do you see a benefit in having the size explicit in IR somehow?

Yes, it should be possible to determine the type offset from the data layout. It’s not mentioned in the proposal, but I already have in mind a pass that substitutes type_offset with arith constants using the data layout.

Now, type_offset exists because there’s no guarantee that a data layout will be available from the start -e.g. in cases where the target has not been determined, and in those cases a different mechanism should exist to express the type offset (addr.type_offset).

[gysit]

@fabianmc

Now, type_offset exists because there’s no guarantee that a data layout will be available from the start -e.g. in cases where the target has not been determined, and in those cases a different mechanism should exist to express the type offset (addr.type_offset).

That makes sense! I was not thinking of such a high-level scenario :).

[fabianmc]

Continuing the discussion here:

[RFC] `ptr` dialect & modularizing ptr ops in the LLVM dialect

TLDR; This RFC proposes the ptr dialect to model pointer and low-level memory operations, providing a generalization of the pointer operations in the LLVM dialect, thus making the operations in the dialect reusable and interoperable with high-level dialects. This RFC is a counter proposal to [RFC] `address` dialect. This proposal arose after chatting with @mehdi_amini , were we agreed that there shouldn’t be type duplication (!llvm.ptr vs address ) and that some ops could be extracted from LLVM…