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

[Alex Voicu]

AlexVlx wrote:

> > I do believe that this is a necessary bit of query-able information, especially from a Clang, for correctness reasons (more on that below).
> 
> I don't think this buys frontends much. Clang still needs to understand the full language address space -> target address space mapping. This would just allow populating one entry generically
> 
> > 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
> 
> As I mentioned above, SPIRV can just work its way out of this problem for its IR. SPIR's only reason for existence is bitcode compatibility, so doing anything with there will be quite a lot of work which will never realistically happen.
> 
> > 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?
> > This is the most generic wording I can come up with so far. Happy to hear more feedbacks.
> 
> I would like to avoid adding additional special properties to AS0, or defining the flat concept.

This is all fine, let's ignore SPIR-V for a second (SPIR being relevant is debatable, and I'm not sure what its reason for being was, but I'm pretty sure nothing is being done with it), and assume that that gets fixed. What is there to prevent some other target coming in and doing the same thing (using 0 to represent some constrained / problematic AS), without placing any sort of additional constraints on 0 (the absence thereof being an issue as it stands), and without giving the FE a mechanism to at least attempt to get flat/flat-like AS? More specifically, how do you expect Clang to figure this out when e.g. compiling C++ for some AS rich target that decided to default to something odd (so querying the correspondent for LangAS::Default is not useful) and uses 0 to denote a special purpose AS (so the many uses of getUnqual/get with the AS argument defaulted end up doing something wrong)? There isn't an awful lot of guidance being provided, you don't want to update LangRef, and the "undesirable" wording is rather opaque to put it mildly.

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