Skip to content

Conversation

@RiverDave
Copy link
Collaborator

@RiverDave RiverDave commented Nov 15, 2025

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 TargetAddressSpaceAttr and couple it with PointerType. 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 existing cir::AddressSpaceAttr/cir::AddressSpace 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 target AS as it is done upstream.
  2. The current implementation of AddressSpaceAttr(which handles an enum) will handle language specific AS (CUDA, OpenCL, etc..).
  3. PointerType will hold: TargetAddressSpaceAttr, AddressSpaceAttr or 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.)
  4. GlobalOps will enforce the rule mentioned above as well via AttrConstraints.
  5. 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).
  6. Bring any extra upstream changes that deviate with what we have here.

However, not in the scope of this PR but my idea is to improve, revamp the later mentioned AddressSpaceAttr and 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:

  • Would it be suitable to rename AddressSpaceAttr (to something like ClangAddressSpaceAttr or LangAddressSpaceAttr) since after this PR — Our previous attribute will no longer support target AS within that attribute?

@RiverDave RiverDave changed the title [CIR][AddrSpace] Backport TargetAddressSpaceAttr and Support both language(clang) and target address-space attributes in pointer types and Global Ops [CIR] Backport TargetAddressSpaceAttr and Support both existing AS and target AS attributes in pointer types and Global Ops Nov 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants