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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
