[CIR] Backport TargetAddressSpaceAttr and Support both existing Lang AS and target AS attributes in pointer types and Global Ops

[RiverDave]

Bringing the changes we performed at: llvm/llvm-project#161028 down to the incubator isn't as straight-forward as I though. Therefore — this PR might be a bit long but hopefully not too complicated, bare with me :)

The main purpose of this is to bring the recent upstreamed TargetAddressSpaceAttr and couple it with PointerType and GlobalOp. The main challenge is that this collides with the already implemented infrastructure related to AS that revolves around our unified enum approach (That handles numeric and lang AS). My main rationale here is that we let our new attribute to coexist with the already existing cir::AddressSpaceAttr (renamed now). so that we don't break any tests related to offload-type languages.

Considering the above what I'm essentially doing is:

1. Letting TargetAddressSpaceAttr handle numeric target AS as it is done upstream.
2. Rename our previous AddressSpaceAttr to ClangAdddressSpaceAttr.
3. The current implementation of ClangAddressSpaceAttr(which handles an enum) will handle language/clang specific AS (CUDA, OpenCL, etc..) it will no longer handle target as it used to!
4. PointerType will hold: TargetAddressSpaceAttr, ClangAddressSpaceAttr or null (default AS). We enforce this via a custom verifier. (I would've preferred to enforce this rule via an AttrConstraint, but apparently that doesn't support types? — At least I couldn't make it work.)
5. GlobalOps will enforce the rule mentioned above as well via AttrConstraints. This works since we can apply constraints to Ops.
6. Adjusted the assembly format for all tests containing any AS attributes to conform with our new format: target_address_space(n)/clang_address_space(x).
7. For the relevant Ops: Default address spaces will now be represented as an empty mlir::Attribute = {}
8. Remove any comments that make reference to our old approach regarding AS handling.
9. Updated description where relevant.
10. Bring any extra upstream changes that deviate with what we have here.

Important!!
Not in the scope of this PR but my idea is to improve, revamp the later mentioned ClangAddressSpaceAttr and incorporate most of the feedback we received in: llvm/llvm-project#161028 (comment). (And yes! I haven't forgotten about the {MemorySpaceAttrInterface} to be coupled with the ptr op).

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[bcardosolopes]

I like the overall direction, thanks for taking the time to improve the holistic approach. One nit is to perhaps rename ClangAdddressSpaceAttr to LangAdddressSpaceAttr. Let's see if other reviewers have more insight here.

(cc @koparasy)

[bcardosolopes]

Is there a plan to eventually merge these two? I feel it's weird to have two different attributes for it, I wonder if it would be more clean if there's a base AddressSpaceAttr and these two different ones are just specializations - using CIR_AnyAddressSpaceAttr for this only work for constraints and it would be nice if in general to pass things around in the terms of the generic version. If so, maybe doing it as part of this PR is a good time.

[RiverDave]

I'm not entirely sure if specializations for attributes can be done in MLIR (I might need to research!).

What we could do is to add MemorySpaceAttrInterface to PointerType as a paremeter (Similar to how it's done in the ptr dialect:

clangir/mlir/include/mlir/Dialect/Ptr/IR/PtrDialect.td

Line 71 in 99388f7

let parameters = (ins "MemorySpaceAttrInterface":$memorySpace);

). This interface would be implemented by both Target and Clang address spaces. This last thing I intended to do in a different PR, but I agree It's not entirely correct in its current state.

If the above makes sense I'll work on it soon.

[koparasy]

I like the overall direction, thanks for taking the time to improve the holistic approach. One nit is to perhaps rename ClangAdddressSpaceAttr to LangAdddressSpaceAttr. Let's see if other reviewers have more insight here.

(cc @koparasy)

I don’t have a strong objection to the implementation itself — the patch is clear and seems consistent with the upstream direction. My only hesitation is around the conceptual cost of introducing two separate address-space attributes. Address spaces are already a tricky area, and users can also influence them via language-level attributes, so reasoning about them tends to get complicated quickly.

Do we have a long-term plan for how TargetAddressSpaceAttr and ClangAddressSpaceAttr are expected to relate to each other? In particular, is the intention that these eventually converge (e.g., via a redesigned ClangAddressSpaceAttr or the MemorySpaceAttrInterface work), or do we expect them to remain distinct? Understanding the roadmap would help me see the benefit of keeping them separate rather than unifying the representation.

[RiverDave]

I like the overall direction, thanks for taking the time to improve the holistic approach. One nit is to perhaps rename ClangAdddressSpaceAttr to LangAdddressSpaceAttr. Let's see if other reviewers have more insight here.
(cc @koparasy)

I don’t have a strong objection to the implementation itself — the patch is clear and seems consistent with the upstream direction. My only hesitation is around the conceptual cost of introducing two separate address-space attributes. Address spaces are already a tricky area, and users can also influence them via language-level attributes, so reasoning about them tends to get complicated quickly.

Do we have a long-term plan for how TargetAddressSpaceAttr and ClangAddressSpaceAttr are expected to relate to each other? In particular, is the intention that these eventually converge (e.g., via a redesigned ClangAddressSpaceAttr or the MemorySpaceAttrInterface work), or do we expect them to remain distinct? Understanding the roadmap would help me see the benefit of keeping them separate rather than unifying the representation.

Hey :) thanks for the comment, we initially had laid down support for it to be unified as it is currently down here in the incubator.

clangir/clang/include/clang/CIR/Dialect/IR/CIREnumAttr.td

Line 44 in 99388f7

def CIR_AddressSpace : CIR_I32EnumAttr<

The decision to split both attributes came from feedback from one of the mantainers of the core mlir dialects. llvm/llvm-project#161028 (comment) (I'd suggest thoroughly looking at the discussion for full context). Our ultimate goal is to align with other upstream dialects, specifically the ptr dialect and how it attaches memory spaces to it. I think It is fair for both of them to remain distinct in CIR at least. They would converge on the lowering stage as LLVM ir can only represent numeric address spaces.

However, I think @xlauko and @andykaylor have more experience designing dialects and at the end — might have a better answer for you.