[Mlir-commits] [clang] [lld] [llvm] [mlir] [IR] Introduce `T<address space>` to `DataLayout` to represent flat address space if a target supports it (PR #108786)

Shilei Tian llvmlistbot at llvm.org
Tue Sep 24 11:29:35 PDT 2024


shiltian wrote:

> Is there a value in not defining 0 as flat?

Like @AlexVlx mentioned, as well as the wording I put into `LangRef.rst`, SPIR/SPIR-V uses AS 4 as flat AS.

> It's what we basically assume everywhere already, isn't it?

I don't think this is technically true, but it is unfortunately practically true. There is no formal definition of what a flat AS is (except the one in TTI which is not widely used at all), which is the central question of this PR. That means all the "assumption everywhere" is basically assumption of every means for its own purpose. The current AS 0 is nothing special but just taken as the default AS for various object allocation if no explicit AS is used. That's all.

> Perhaps another solution(?) here would be to tweak LangRef to be binding in that it spells out that iff a particular Target has a Flat AS, that will be reflected in LLVM as AS0?

I'm fine with adding the enforcement in LLVM that AS0 needs to be the flat AS, if a target has it, but the definition of a flat AS still needs to be set. If we do that, how will SPIR/SPIR-V work?

---

I think to have a clear definition of what a flat AS is critical, no matter if we want to add a new specification, as what is done is this PR, or add the wording into LLVM LangRef, enforcing it to AS 0. I'd like to give it a try here. ⬇️

---

A flat address space is an address space with the following characteristics:

1. It must correspond to an existing address space; defining a flat address space does not create a new address space.
2. Pointers in this address space can be used to access multiple memory segments, each associated with distinct address spaces.
3. Accessing memory through a pointer in this address space **may** be slower than accessing memory through a pointer in a more specific address space.
4. Pointers in this address space must be able to be losslessly converted **to** other address spaces.

All other characteristics of the flat address space will align with those of the original existing address space.

https://github.com/llvm/llvm-project/pull/108786


More information about the Mlir-commits mailing list