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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
