[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros
Anastasia Stulova via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Nov 23 10:47:25 PST 2020
Anastasia added a comment.
In D91531#2411725 <https://reviews.llvm.org/D91531#2411725>, @azabaznov wrote:
>> Perhaps if you give me an example it would help to understand
>
> I was meant that this can potentially be used to undefine macros inside clang directly. In this case there will no need to add a lot of conditional preprocessor directives in the header, also the existing interface (`-cl-ext=-cl_khr_depth_images`) will be preserved. So for example in the header there was specified an extension definition. Can undef directive be allocated and bound to a specific source location right after extension definition if `-cl-ext=-cl_khr_depth_images` was specifed:
>
> #if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0) || \
> (__OPENCL_C_VERSION__ >= CL_VERSION_1_2 && defined(__SPIR__) )
> #define cl_khr_depth_images 1
> #endif
>
> // Bind undef directive here
>
> I understand that this sounds tricky, but preserving interface sound reasonable for me.
Yes, preserving the interface is not unreasonable indeed. So if I understand it well you are suggesting to perform a check for every parsed macro definition that would identify whether the macro has a name matching what is provided in `-cl-ext=`? Then if the name matches it would check whether the macro should be defined or not? I feel this might be a bit too costly to justify the gain. That means that not every user would agree on such a mechanism to be enabled by default i.e. it means we would need to provide an alternative interface anyway.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D91531/new/
https://reviews.llvm.org/D91531
More information about the cfe-commits
mailing list