[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