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();
----------------
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.


================
Comment at: lib/CodeGen/CodeGenTypes.h:200
+  /// Get the LLVM pointer type of a variable.
+  llvm::PointerType *getVariableType(VarDecl D);
+
----------------
t-tye wrote:
> Should the name reflect that the type returned is not the variable type, but 
> a pointer to the variable type? For example, getVariablePointerType or 
> getPointerToVariableType.
I think getPointerToVariableType is better. I will change it.


https://reviews.llvm.org/D32248



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to