<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>