[PATCH] D32248: CodeGen: Cast alloca to expected address space

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.


================
Comment at: lib/CodeGen/CGDecl.cpp:1105-1119
+  // Alloca always returns a pointer in alloca address space, which may
+  // be different from the type defined by the language. For example,
+  // in C++ the auto variables are in the default address space. Therefore
+  // cast alloca to the expected address space when necessary.
+  auto Addr = address.getPointer();
+  auto AddrTy = cast<llvm::PointerType>(Addr->getType());
+  auto ExpectedAddrSpace = CGM.getTypes().getVariableType(D)->getAddressSpace();
----------------
yaxunl wrote:
> t-tye wrote:
> > Is any assert done to ensure that it is legal to address space cast from variable address space to expected address space? Presumably the language, by definition, will only be causing legal casts. For example from alloca address space to generic (which includes the alloca address space).
> > 
> > For OpenCL, can you explain how the local variable can have the constant address space and use an alloca for allocation? Wouldn't a constant address space mean it was static and so should not be using alloca? And if it is using an alloca, how can it then be accessed as if it was in constant address space?
> If the auto var has address space qualifier specified through `__attribute__((address_space(n)))`, there is not much we can check in clang since it is target dependent. We will just emit address space cast when necessary and let the backend check the validity of the address space cast.
> 
> Otherwise, for OpenCL, we can assert the expected address space is default (for OpenCL default address space in AST represents private address space in source language) or constant. For other languages we can assert the expected address space qualifier is default (no address space qualifier). It is not convenient to further check whether the emitted LLVM address space cast instruction is valid since it requires target specific information, therefore such check is better deferred to the backend.
> 
> For OpenCL, currently automatic variable in constant address space is emitted in private address space. For example, currently Clang does not diagnose the following code
> 
> ```
> void f(global int* a) {
>   global int* constant p = a;
> }
> 
> ```
> Instead, it emits alloca for p, essentially treats it as `global int* const p`. This seems to be a bug to me (or maybe we can call it a feature? since there seems no better way to translate this to LLVM IR, or simply diagnose this as an error). However, this is better addressed by another patch.

Hi Anastasia,

Any comments about the automatic variable in constant address space? Thanks.


https://reviews.llvm.org/D32248