<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);">
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>(https://clang.llvm.org/docs/UsersManual.html#opencl-header). 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>https://reviews.llvm.org/D78979. 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>(https://llvm.org/devmtg/2019-10/talk-abstracts.html#lit5). 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>
</body>
</html>