[CIR][Dialect] Add address space attribute to global op

[seven-mile]

This PR adds the CIR address space attribute to GlobalOp and starts to resolve the missing feature flag addressSpaceInGlobalVar.

The same asm format in pointer type is used:

cir.global external addrspace(offload_global) @addrspace1 = #cir.int<1> : !s32i

The parsing and printing helper is extracted into a common function to be reused by both GlobalOp and PointerType with two custom format proxy to it. That's because the signature of ODS generated method differs from the one for PointerType.

Lowering to LLVM IR and CIRGen will come sequentially.

[bcardosolopes]

LGTM. For next PRs: what happens if a global has a type that has a different address space, is that possible?

[seven-mile]

Not sure if I got it! FYI: It seems there are two main aspects here, which are somewhat similar to the alloca address space handling:

• For the get_global op's pointer type, it should be inferred within the CIR builder, which shall be included in one of the CIRGen PRs (num > 1 for sure).
• If the AST requires other address spaces (as determined by CGM.getGlobalVarAddressSpace() based on the favor of language and target info), an addrspacecast will be inserted by CodeGen. However, this cast will not occur for the OpenCL C + SPIR-V target.

Aside from these CIRGen changes, it might be worth considering adding proper verification for get_global, correct?

[bcardosolopes]

• For the get_global op's pointer type, it should be inferred within the CIR builder, which shall be included in one of the CIRGen PRs (num > 1 for sure).
• If the AST requires other address spaces (as determined by CGM.getGlobalVarAddressSpace() based on the favor of language and target info), an addrspacecast will be inserted by CodeGen. However, this cast will not occur for the OpenCL C + SPIR-V target.

Got it, so if we write .cl code where __attribute__ is used for a global, does that get ignored in favor of the default one then?

Aside from these CIRGen changes, it might be worth considering adding proper verification for get_global, correct?

Right, assuming that construct doesn't make sense.

[seven-mile]

Got it, so if we write .cl code where __attribute__ is used for a global, does that get ignored in favor of the default one then?

Actually it will be rejected by Sema. And there is not a "default one", sorry for the confusion here: the method has a parameter VarDecl *D in fact.

CGM.getGlobalVarAddressSpace(VarDecl *D) implemented by different languages may have different favor on how to fetch the result AS. OpenCL and SYCL respect D->getType()->getAddressSpace(), but CUDA uses their own UnitAttrs to identify AS instead: CUDAConstantAttr, CUDADeviceAttr... This method is abstracted to provide considerable design freedom on this issue.