frasercrmck wrote: > LGTM. That means we compile for the last OpenCL version, which is 3.0, and > enable all OpenCL extensions/features, right? libclc is implemented using > functions supported by clang, so it is unlikely a target has libclc build > error in generic libclc files that are shared for all targets. When libclc is > linked to application module, libclc built-ins implementation of unsupported > extensions/features won't be linked in because these built-ins won't exist in > the user module. If the application code uses an unsupported extension, > frontend would report error already. There could be problem if application > modules links in a supported libclc built-in function which calls another > libclc built-in that belongs to unsupported special extension/feature, but I > think this scenario is unlikely and the supported built-in should be fixed to > not using unsupported feature. @frasercrmck What do you think?
Sounds good to me. I hope that by having the internal CLC library we can largely avoid the last scenario, as CLC should be less dependent on the OpenCL C version. An OpenCL 1.2 module could still call a builtin that makes internal use of CLC `ctz`, for example. Anyway, sorry for complicating the PR with my suggestion. I was being unnecessarily conservative. https://github.com/llvm/llvm-project/pull/135733 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
