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

[Anastasia Stulova via cfe-dev]

Hi David,

We were slightly inclined towards option 2 for now which means if a library-only feature is passed to '-cl-ext', the frontend will implicitly define a macro. We will probably want to add a warning for this or something but the details can be refined in the review.

However, as a temporary solution, we could also go for option 1 at it might be easier to implement.

If you would like to create a patch I or Anton can take a look and review it.

Cheers,
Anastasia
________________________________
From: David Airlie <airlied at redhat.com>
Sent: 05 August 2021 08:57
To: Anastasia Stulova <Anastasia.Stulova at arm.com>
Cc: cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>; anton.zabaznov at intel.com <anton.zabaznov at intel.com>
Subject: Re: SPIR target enables all CL optional extensions

On Thu, Jul 8, 2021 at 8:28 AM David Airlie <airlied at redhat.com> wrote:
>
> 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.

Was there any followup on this from the Tooling teleconf?

I'm back at having to remove the #if (__SPIR__) define everything as I
want to use
SPIRV internally in my compiler without all the extensions defined.

Dave.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210805/3e0e7b62/attachment-0001.html>