[cfe-dev] SPIR target enables all CL optional extensions

David Airlie via cfe-dev cfe-dev at lists.llvm.org
Wed Jul 7 15:28:15 PDT 2021

On Wed, Jul 7, 2021 at 10:36 PM Anastasia Stulova
<Anastasia.Stulova at arm.com> wrote:
> Correct some of the feature macros that add features through the libraries are
> now unconditionally defined in the internal header files. Although clang was
> always setting all optional features to supported ones for generic targets like
> SPIR however there was a frontend-only flag '-cl-ext' that allowed to override
> this.

> We have started the discussion to restore this functionality for library-based
> features and here are two short-term approaches that have been discussed so
> far:
> 1. Use '-D__undef_<feature name>' flag to skip defining the macros. I have
> created an RFC patch to demonstrate the idea earlier:
> https://reviews.llvm.org/D91531
> 2. Extend '-cl-ext' interface to handle such features.
> Anton has been looking at this in:
> https://reviews.llvm.org/D103241?id=348222#inline-97980
> Overall, originally SPIR has been added to clang as a device-agnostic target in
> a primary use case. But I feel in a long term we should consider improving the
> design by adding an ability to specify a concrete device or maybe a class of
> devices compiled for. Otherwise, I don't think always enumerating the list of
> features/extensions using '-cl-ext'/'-D' with each clang invocation is extremely
> usable. So this area definitely needs some improvements.

Yes for mesa/clover, we don't want SPIR to be device-agnostic, we want
to give clang the list of supported extensions and have
opencl-c.h work with that. At the moment even if I give it the
supported extensions I expect I'd fall over the __SPIR__ turns
on all exts in opencl-c.h.


> FYI this topic is being discussed in the scope of OpenCL Tooling
> teleconferences within Khronos. The next session is on Thu next week.

I'll keep an eye on this, probably not timezone compatible with me.


More information about the cfe-dev mailing list