[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D91531#2418237 <https://reviews.llvm.org/D91531#2418237>, @mantognini wrote:

> When reading the documentation [1] for -cl-ext (which I've never used so far), I've noticed nothing is said about non-standard configurations (such as disabling cl_khr_depth_images with CL2.0). Quickly testing this shows that options can be specified to produce non-standard behaviour, as shown by https://godbolt.org/z/1Yz1Md.
>
> Is it intentional that -cl-ext allows such non-standard behaviour? (This question is not necessarily address to @Anastasia.)
> /If so/, then these statements
>
>> Defining __undef_cl_khr_depth_images can alter the default behavior of the predefined macro. This is equivalent to passing -cl-ext=-cl_khr_depth_images.
>
> and
>
>> cl_khr_depth_images is a core functionality of CL2.0 and thefore defining __undef_cl_khr_depth_images doesn't modify the default behavior.
>
> are slightly contradicting each other: the approach with __undef macros seems to ensure a more conformant behaviour.
>
> I'm mainly asking for clarification in order to know in which direction we want to go, as one could also argue the present documentation doesn't imply non-standard behaviour is desired and that the current implementation of -cl-ext is buggy.
>
> [1] https://clang.llvm.org/docs/UsersManual.html#cmdoption-cl-ext

Thanks! This is a very good point. I am not entirely clear of the intended use case. In this patch I have only tried to preserve existing functionality. To my memory the flag was added to simplify life of downstream implementations. However if the intent of it is not clear now perhaps it shouldn't really be part of upstream code base. Otherwise all it does is complicating future development. I suggest we try to clarify the following:

1. How/where `-cl-ext` is used.
2. Does its use (if any) still justify maintenance and further development?
3. Do we need equivalent functionality for extensions that are not part of clang i.e. library extensions?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91531/new/

https://reviews.llvm.org/D91531