[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] SPIR target enables all CL optional extensions
From: Anastasia Stulova via cfe-dev <cfe-dev () lists ! llvm ! org>
Date: 2021-08-05 9:23:33
Message-ID: DB6PR08MB2824291AA1E23C46E187425BF0F29 () DB6PR08MB2824 ! eurprd08 ! prod ! outlook ! com
[Download RAW message or body]
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@redhat.com>
Sent: 05 August 2021 08:57
To: Anastasia Stulova <Anastasia.Stulova@arm.com>
Cc: cfe-dev (cfe-dev@lists.llvm.org) <cfe-dev@lists.llvm.org>; \
anton.zabaznov@intel.com <anton.zabaznov@intel.com>
Subject: Re: SPIR target enables all CL optional extensions
On Thu, Jul 8, 2021 at 8:28 AM David Airlie <airlied@redhat.com> wrote:
>
> On Wed, Jul 7, 2021 at 10:36 PM Anastasia Stulova
> <Anastasia.Stulova@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.
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} \
</style> </head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> Hi David,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> 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.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> However, as a temporary solution, we could also go for option \
1 at it might be easier to implement.</div> <div style="font-family: Calibri, Arial, \
Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br>
</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> If you would like to create a patch I or Anton can take a look and \
review it.</div> <div style="font-family:Calibri,Arial,Helvetica,sans-serif; \
font-size:12pt; color:rgb(0,0,0)"> <br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> Cheers,<br>
Anastasia<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, \
sans-serif" color="#000000"><b>From:</b> David Airlie <airlied@redhat.com><br> \
<b>Sent:</b> 05 August 2021 08:57<br> <b>To:</b> Anastasia Stulova \
<Anastasia.Stulova@arm.com><br> <b>Cc:</b> cfe-dev (cfe-dev@lists.llvm.org) \
<cfe-dev@lists.llvm.org>; anton.zabaznov@intel.com \
<anton.zabaznov@intel.com><br> <b>Subject:</b> Re: SPIR target enables all CL \
optional extensions</font> <div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">On Thu, Jul 8, 2021 at 8:28 AM David Airlie \
<airlied@redhat.com> wrote:<br> ><br>
> On Wed, Jul 7, 2021 at 10:36 PM Anastasia Stulova<br>
> <Anastasia.Stulova@arm.com> wrote:<br>
> ><br>
> > Correct some of the feature macros that add features through the libraries \
are<br> > > now unconditionally defined in the internal header files. Although \
clang was<br> > > always setting all optional features to supported ones for \
generic targets like<br> > > SPIR however there was a frontend-only flag \
'-cl-ext' that allowed to override<br> > > this.<br>
><br>
> ><br>
> > We have started the discussion to restore this functionality for \
library-based<br> > > features and here are two short-term approaches that have \
been discussed so<br> > > far:<br>
> ><br>
> > 1. Use '-D__undef_<feature name>' flag to skip defining the macros. I \
have<br> > > created an RFC patch to demonstrate the idea earlier:<br>
> > <a href="https://reviews.llvm.org/D91531">https://reviews.llvm.org/D91531</a><br>
> ><br>
> > 2. Extend '-cl-ext' interface to handle such features.<br>
> > Anton has been looking at this in:<br>
> > <a href="https://reviews.llvm.org/D103241?id=348222#inline-97980">https://reviews.llvm.org/D103241?id=348222#inline-97980</a><br>
> ><br>
> > Overall, originally SPIR has been added to clang as a device-agnostic \
target in<br> > > a primary use case. But I feel in a long term we should \
consider improving the<br> > > design by adding an ability to specify a \
concrete device or maybe a class of<br> > > devices compiled for. Otherwise, I \
don't think always enumerating the list of<br> > > features/extensions using \
'-cl-ext'/'-D' with each clang invocation is extremely<br> > > usable. So this \
area definitely needs some improvements.<br> ><br>
> Yes for mesa/clover, we don't want SPIR to be device-agnostic, we want<br>
> to give clang the list of supported extensions and have<br>
> opencl-c.h work with that. At the moment even if I give it the<br>
> supported extensions I expect I'd fall over the __SPIR__ turns<br>
> on all exts in opencl-c.h.<br>
<br>
Was there any followup on this from the Tooling teleconf?<br>
<br>
I'm back at having to remove the #if (__SPIR__) define everything as I<br>
want to use<br>
SPIRV internally in my compiler without all the extensions defined.<br>
<br>
Dave.<br>
<br>
</div>
</span></font></div>
</body>
</html>
[Attachment #4 (unknown)]
_______________________________________________
cfe-dev mailing list
cfe-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic