Anastasia 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:
> 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.
From the spec s6.5.3 it feels like we should follow the same implementation
path in Clang for constant AS inside kernel function as local AS. Because
constant AS objects are essentially global objects.
Although, we didn't have any issues up to now because const just does the
trick of optimising the objects out eventually. I am not clear if this creates
any issue now with your allocation change. It feels though that it should
probably work fine just as is?
https://reviews.llvm.org/D32248
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
