[RFC] `address` dialect

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.

2 Likes