[PATCH] D33989: [OpenCL] Allow targets to select address space per type
Richard Smith - zygoloid via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Nov 16 13:24:42 PST 2017
rsmith added inline comments.
================
Comment at: cfe/trunk/lib/Basic/TargetInfo.cpp:351
+LangAS::ID TargetInfo::getOpenCLTypeAddrSpace(const Type *T) const {
+ auto BT = dyn_cast<BuiltinType>(T);
----------------
Anastasia wrote:
> chapuni wrote:
> > Excuse me for old commit, I think it might be layering violation.
> > Could we avoid using AST/Type here?
> One of the problems is that even if we could write another layer of enums to map OpenCL specific AST types into the TargetInfo representation it doesn't really help creating a layered structure between AST and Basic libs. They seem to have a large logical dependence despite not including the library headers physically. So modification in AST would require modifications in Basic anyway resulting in overhead of changing 2 places instead of 1. So I am wondering if there is any better approach here e.g. revisiting the library dependencies or what classes they should contain?
I don't know what large logical dependencies you're talking about here. `Basic` is supposed to be answering questions about lowering that are independent of our choice of AST model. It should never look at a `clang::Type` for any reason to do this, and should never need to do so. If you find it does need to do so, you're asking the `TargetInfo` questions at the wrong level of abstraction.
As far as I can see, there's only one question you actually need to ask the `TargetInfo` here, and that's whether builtin types are in the `opencl_global` or `opencl_constant` address space.
Repository:
rL LLVM
https://reviews.llvm.org/D33989
More information about the cfe-commits
mailing list