<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<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);">
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:#000000">Thanks for your input James! I am wondering what your concerns are regarding the Tablegen-based declarations. It would be great
if you could elaborate on that.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:#000000">To give some background: we have looked into modules and PCH some time ago and found Tablegen is the only acceptable solution
currently. The problem with modules is that the serialized format (same as PCH) occupies a lot of memory, which is a concern for devices where the compiler is part of the device driver. We have investigated various ways to reduce the size but it was not very
easy due to the generality of the serialization format. The techniques we looked at had low chances to be accepted by a wider community and they were not extremely effective either. Another drawback with modules is that a separate cached binary would be needed
for each combination of command-line options: a language version + target configurations including extensions. This would mean that a lot of memory would be needed for just declaring the OpenCL functions not only per one module but different build configurations
too.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:#000000">After multiple investigations, we have concluded that the more targeted Tablegen approach was the best solution to satisfy the
requirements. Of course we could have a module-based approach for offline compilations and a custom one for online compilations. But then we would have to develop and maintain two mechanisms. We do have two mechanisms now but hopefully, we can migrate to Tablegen
one very soon. Some background about the issues is summarized in the original proposal:
</span><a href="https://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html"><span style="font-size:11pt;font-family:Arial;color:#1155cc;text-decoration:underline;text-decoration-skip-ink:none">https://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html</span></a>.</p>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br>
</p>
<div dir="ltr" style="line-height: 1.38; margin-top: 0px; margin-bottom: 0px;"><span style="font-size:11pt;font-family:Arial;color:#000000">Regarding your suggestion of the command line interface: I like the idea of mixing the regular header with the Tablegen
declarations. The only concern is that the header with regular declarations could still be long to parse but I believe it would not be significant at the moment. Aside from simplifying the command line interface, we can use it for the future development to
mitigate the complexity i.e. some simple and fast-to-parse declarations can just be added in the header to bypass the Tablegen syntax. This should also be simple enough to implement because we are already adding an extra header file declaring the types with
the Tablegen declarations that can be reused for missing functionality too or additionally we could add a separate header for those.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-top: 0px; margin-bottom: 0px;"><span style="font-size:11pt;font-family:Arial;color:#000000"><br>
</span></div>
<div dir="ltr" style="line-height: 1.38; margin-top: 0px; margin-bottom: 0px;"><span style="font-size:11pt;font-family:Arial;color:#000000">Cheers,</span></div>
<div dir="ltr" style="line-height: 1.38; margin-top: 0px; margin-bottom: 0px;"><span style="font-size:11pt;font-family:Arial;color:#000000">Anastasia</span><br>
</div>
</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<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> James Y Knight <jyknight@google.com><br>
<b>Sent:</b> 05 February 2021 22:12<br>
<b>To:</b> Anastasia Stulova <Anastasia.Stulova@arm.com><br>
<b>Cc:</b> clang developer list <cfe-dev@lists.llvm.org>; nd <nd@arm.com>; Sven Van Haastregt <Sven.VanHaastregt@arm.com><br>
<b>Subject:</b> Re: [cfe-dev] [RFC][OpenCL] Add builtin types and functions from the standard headers implicitly in the driver</font>
<div> </div>
</div>
<div>
<div dir="ltr">The whole tablegen thing seems like a sad path to have gone down, although I can certainly see the practical benefits. Substantially the same problem of compilation-speed exists for <x86intrin.h> (and friends), and I really don't think we want
to start defining all of <i>those</i> with a tablegen rule.
<div><br>
</div>
<div>It would be really nice to instead somehow take advantage of the modules infrastructure to fix this problem -- I'd really love it if we could somehow start shipping a pre-built module artifact for our giant intrinsics headers, included with the compiler
distribution. And then use that by default, regardless of whether users are otherwise enabling modules. If we got that to work, we could use the same solution for both X86 and opencl.</div>
<div>
<div><br>
</div>
<div><br>
</div>
<div>However, independent of that discussion -- and more to the immediate issue you're trying to raise -- your proposal seems like it's resulting in a very complex set of options, and I'm not sure what the purpose is.</div>
<div><br>
</div>
<div>IIUC, the overall desire is to have, by default, these tens-of-thousands of prototypes available to all OpenCL compilations. But, I don't see any reason why users should care exactly HOW these are provided. I'd expect that a given prototype should be provided
either by the tablegen-based builtin code, OR an auto-included header file -- not both, and not neither. </div>
<div><br>
What difference does it make if the builtin-tablegen code doesn't provide 100% of the declarations, so long as the remainder are provided by an automatically-included header? Why do you want to make users choose between getting a half-baked set of function
prototypes (tablegen version) and slow compilation (auto-including giant header), when you can have the fully correct set of functions AND nearly-as-fast compilation, by simply supplementing tablegen with an auto-included header providing the remainder?</div>
<div><br>
</div>
<div>And then you need just a single user-visible option: to disable the automatic declarations (via both tablegen + autoinclude).<br>
</div>
<div></div>
</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Wed, Feb 3, 2021 at 11:58 AM Anastasia Stulova via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hello,</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)">
I would like to check if there is any feedback to the following proposal for</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
improving the interface of standard type and function includes.<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)">
Background
<div><br>
</div>
<div>Currently the default clang driver provides incomplete functionality for OpenCL
</div>
<div>because the headers with builtin function declarations are not included by </div>
<div>default. The header can only be added using frontend flags requiring ‘-cc1’ or
</div>
<div>other frontend forwarding options</div>
<div>(<a href="https://clang.llvm.org/docs/UsersManual.html#opencl-header" target="_blank">https://clang.llvm.org/docs/UsersManual.html#opencl-header</a>). This means it</div>
<div>is inaccessible to users in a conventional way. </div>
<div><br>
</div>
<div>We propose to add the implicit header by default when a source is compiled in
</div>
<div>OpenCL mode. A review for this has been uploaded by Matt a few months ago:</div>
<div><a href="https://reviews.llvm.org/D78979" target="_blank">https://reviews.llvm.org/D78979</a>. Note that the standard library functionality is
</div>
<div>added by default in OpenCL C without using include directives in the compiling
</div>
<div>sources. This means all builtin function declarations (there are 17000 of </div>
<div>them) are to be parsed every time the source is compiled because which builtins
</div>
<div>are used by the kernels is not known beforehand. This impacts the compilation
</div>
<div>speed. For example, parsing a simple kernel with the builtin function </div>
<div>declarations is 138 times slower in a Debug build and 13 times slower in a </div>
<div>Release build than parsing the same kernel without those declarations. </div>
<div><br>
</div>
<div>To mitigate the overhead of parsing the full header, a fast Tablegen based </div>
<div>solution has been developed</div>
<div>(<a href="https://llvm.org/devmtg/2019-10/talk-abstracts.html#lit5" target="_blank">https://llvm.org/devmtg/2019-10/talk-abstracts.html#lit5</a>). The parsing speed with</div>
<div>this mechanism for builtin function declarations is only 1.3 times slower in a Debug</div>
<div>build and 1.05 times slower in a Release build compared to clang without the</div>
<div>builtins. While this mechanism covers most of OpenCL standard </div>
<div>functions it lacks two main classes of builtins: builtins defined by </div>
<div>vendor extensions and builtins with enum arguments. </div>
<div><br>
</div>
<div>Proposal </div>
<div><br>
</div>
<div>We propose the following changes in the clang driver interface for OpenCL: <br>
</div>
<div>- Enable the fast Tablegen based builtin function declaration mechanism by </div>
<div>default in the clang driver. This makes the majority of OpenCL builtin </div>
<div>functions available.</div>
<div>- In addition, include the small header opencl-c-base.h by default in the clang</div>
<div>driver. This header provides basic types and constants.</div>
<div>No frontend or driver flags will be needed to allow using the majority of OpenCL
</div>
<div>types and functions from the standard, at a very low parsing speed increase.
</div>
<div><br>
</div>
<div>Since the Tablegen mechanism has some small overhead and it is not fully </div>
<div>complete, we propose to add the following additional clang driver flags:</div>
<div>1. Add a new clang driver flag -cl-no-stdinc (*) that disables such extra includes to
</div>
<div>minimize further compilation speed or for the use cases that don’t require </div>
<div>standard libraries. The majority of OpenCL clang tests will use this option.</div>
<div>2. [Optionally, if there is enough interest] Add a new clang driver flag</div>
<div>-cl-all-stdinc (*) that will include the full header instead of using the Tablegen
</div>
<div>mechanism, at the cost of a significant increase in parsing time. </div>
<div><br>
</div>
<div>At present we propose no change to the ‘cc1’ interface, but in the future it is
</div>
<div>expected that the functionality will be aligned between driver and frontend </div>
<div>command line interfaces for the OpenCL headers. </div>
<div><br>
</div>
<div>(*) The exact spelling of command line options is to be discussed. </div>
<div><br>
</div>
<div>Summary </div>
<div><br>
</div>
<div>This proposal enhances the clang driver with full functionality of OpenCL C by
</div>
<div>adding builtin function declarations implicitly without the need for any </div>
<div>frontend flags to be given in the command line. </div>
<div><br>
</div>
<div>The default clang behavior proposed is not expected to negatively impact users
</div>
<div>of clang as the parsing speed difference remains within the same order of </div>
<div>magnitude. While the fast header mechanism matures, a fallback mechanism will
</div>
<div>be provided if needed that would allow switching to the slow header with the
</div>
<div>full functionality using a new driver flag. For backward compatibility, another
</div>
<div>flag is provided to disable all OpenCL declarations that are not builtin into
</div>
<div>the compiler. </div>
<div><br>
</div>
<div>The solution proposed improves the driver interface and reduces risks of </div>
<div>forcing the OpenCL community to update their use of clang due to significant
</div>
regression of the compilation speed. <br>
</div>
</div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote>
</div>
</div>
</body>
</html>