[CIR] Backport TargetAddressSpaceAttr and Support both existing AS and target AS attributes in pointer types and Global Ops
#1986
+260
−58
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 complicated, bare with me :)
The main purpose of this is to bring the recent upstreamed
TargetAddressSpaceAttrand couple it withPointerType. The main challenge is that this collides with the already implemented infrastructure related to AS that revolves around our unified enum approach. My main rationale here is that we let our new attribute to coexist with the already existingcir::AddressSpaceAttr/cir::AddressSpaceso that we don't break any tests related to offload-type languages.Considering the above what I'm essentially doing is:
TargetAddressSpaceAttrhandle target AS as it is done upstream.AddressSpaceAttr(which handles an enum) will handle language specific AS (CUDA, OpenCL, etc..).PointerTypewill hold:TargetAddressSpaceAttr,AddressSpaceAttror null. 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.)GlobalOpswill enforce the rule mentioned above as well via AttrConstraints.target_address_space(n)/clang_address_space(x).However, not in the scope of this PR but my idea is to improve, revamp the later mentioned
AddressSpaceAttrand incorporate most of the feedback we received in: llvm/llvm-project#161028 (comment) — ideally to handle Language AS as I've mentioned. (And yes! I haven't forgotten about the {MemorySpaceAttrInterface} to be coupled with the ptr op).A couple of extra nits:
AddressSpaceAttr(to something likeClangAddressSpaceAttrorLangAddressSpaceAttr) since after this PR — Our previous attribute will no longer support target AS within that attribute?