[PATCH] D35082: [OpenCL] Add LangAS::opencl_private to represent private address space in AST

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.



> (*) I know that you aren't considering OpenCL C++ yet, but often these representation/model questions are easier to answer when thinking about C++ instead of C because type differences are so much more directly important in C++.  In OpenCL C++, I assume it will be important to distinguish between <int> and <__private int> as template arguments.  That tells us straight up that __private needs to be represented differently from a lack of qualifier.  Note that the result, where certain type representations (e.g. an unqualified int*) become basically meaningless and should never be constructed by Sema, is already precedented in Clang: ObjC ARC does the same thing to unqualified ObjC pointer types, like id*.

It's pretty complicated in OpenCL as `int` and `private int` won't be different, but  `int*` and `private int*` would be different only in OpenCL2.0. The rules are pretty convoluted and I have summarized them in the table earlier: https://reviews.llvm.org/D35082#inline-327303. The issue is that there is not anything like this in other languages and therefore we have this issue trying to fit this concept with something similar but not exactly the same. I thought you and Sam decided to use implicit AS flag to make printing messages consistent with the original source code. I am fine with this approach, however, I would prefer to just keep no AS qualifier in the default AS mode instead of deducing it during parcing in `processTypeAttrs`, and only to add the AS to the IR at the end of the CodeGen phase. I think it would be a lot easier to understand. However, as Sam has pointed out a lot of code in Sema has been written assuming the deduction of AS and is using AS qualifiers explicitly and therefore it seems like it would be a bigger change to go for. At the same type we have refactored the deduction of default AS now in the parcing phase and it looks a lot better than I thought it would be. So I don't mind if we continue this way.


https://reviews.llvm.org/D35082