[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)

[Alex Voicu]

AlexVlx wrote:

> I am personally not opposed to the DL solution, but I guess it's a big change that feels too much for me to approve. I'm also worried the "flat" concept is a special case of something more generic and we should instead define that. E.g.,

In reply to your question above re whether this is a DL or a Target property, I don't have a strong opinion there (it appears @shiltian and @arsenm might). I do believe that this is a necessary bit of query-able information, especially from a Clang, for correctness reasons (more on that below).

> * Does flat imply all AS can cast to it? If so, what happens if that is not true anymore in the future. If it's not implied, how do we query what's allowed and what is not?

To make this generically useful, it probably should, but I don't think the current words imply it.

> * Is there a value in not defining 0 as flat? It's what we basically assume everywhere already, isn't it?

Ah, this is part of the challenge - we do indeed assume that 0 is flat, but Targets aren't bound by LangRef to use 0 to denote flat (and some, like SPIR / SPIR-V) do not, but rather problematically use 0 to denote Private, which is extremely constrained. This leads to problematic IR, due to the assumption you mentioned. An example I ran into the other day is [`emitCalloc`](https://github.com/llvm/llvm-project/blob/5dc15ddf575978e0115b1a6edacb59f056792a80/llvm/lib/Transforms/Utils/BuildLibCalls.cpp#L1989) - note it just uses the default pointer type for its return, which is problematic unless 0 is flat(-ish). It is, of course, fixable via other means, but it's just an example of where we rely on 0 just working. 

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? 



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