ebevhan added a comment. >> I'll have to see if that's possible without breaking a few more interfaces, >> since you can throw around Qualifiers and check for compatibility without an >> ASTContext today. >> >>> I was just thinking about testing the new logic. Should we add something >>> like `-ffake-address-space-map` >>> (https://clang.llvm.org/docs/UsersManual.html#opencl-specific-options) that >>> will force targets to use some implementation of fake address space >>> conversions? It was quite useful in OpenCL before we added concrete targets >>> with address spaces. Alternatively, we can try to use SPIR that is a >>> generic Clang-only target that has address spaces. >> >> Well, there are a couple targets which have target address spaces even >> today, I think. AMDGPU should be one, right? > > Yes, however I am not sure we will be able to test more than what we test > with OpenCL. Also I am not sure AMD maintainer would be ok. Do you have any > concrete idea of what to test?
Well, since there is a mapping from the OpenCL address spaces to the AMDGPU target spaces, I would presume that if the target spaces were used on their own (via `__attribute__((address_space(1)))` for example) they should behave similarly to their OpenCL counterparts. It wouldn't have to be much, just a couple of type definitions and checks for implicit/explicit cast behavior. There's also the x86 case I mentioned. I'm not really sure how that feature is used, though. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62574/new/ https://reviews.llvm.org/D62574 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
