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

We would like to ask for feedback regarding testing strategies for the large </div>

<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">

<div>amount of OpenCL builtin function declarations. </div>

<div><br>

</div>

<div>==========<br>

</div>

<div>Background: </div>

<div>==========</div>

<div><br>

</div>

<div>The OpenCL standard has many builtin functions [1] implicitly declared during

</div>

<div>the kernel compilation. The regular opencl-c.h header in clang containing all

</div>

<div>declarations is nearly 17K lines and it is therefore very expensive in terms of

</div>

<div>compilation time to include. This has caused issues with its testing because

</div>

<div>clang-check testing time is affected. This is one of the main reasons it has

</div>

<div>been tested very sparsely (~150 lines of tests) so far in llvm-project. The full</div>

<div>functionality is being tested outside of llvm-project in various vendor and</div>

<div>open-source tooling projects. However, it doesn’t help to detect issues during</div>

<div>development cycles in llvm-project. </div>

<div><br>

</div>

<div>In the meantime we have developed a new mechanism to implicitly include the </div>

<div>function declarations leveraging Tablegen[2][3][4] that addressed parsing speed</div>

<div>and other limitations. However, the testing has still remained sparse due to the</div>

<div>time considerations. This proposal is addressing testing limitations of OpenCL</div>

<div>builtin functions declared via Tablegen approach and it is based on the detailed</div>

<div>discussions in [5]. Below we present a summary of some options that we have</div>

<div>found promising and invite for feedback to help us define the directions. <br>

</div>

<div><br>

</div>

<div>================<br>

</div>

<div>Testing Alternatives: </div>

<div>================</div>

<div><br>

</div>

<div>(1) Standard testing via clang invocation and use of -verify. </div>

<div><br>

</div>

<div>This is a regular straightforward format of testing that aims at checking that</div>

<div>headers can be parsed for various configurations. Similar tests are already part</div>

<div>of clang test suite, e.g. Headers/arm-neon-header.c or</div>

<div>Headers/x86-intrinsics-headers.c. </div>

<div><br>

</div>

<div>In contrast for our case we would like to call each overload of builtin functions to</div>

<div>verify the right functionality is exposed through the header. The tests could be</div>

<div>written manually from scratch or auto-generated initially and then manually</div>

<div>evolved/maintained. It is expected that the test file will be quite large - the</div>

<div>auto-generated version currently has about 60K lines (see details in [5]). For</div>

<div>comparison, the largest test file in clang is currently around 20K lines. It is</div>

<div>possible to partition into multiple test files but it doesn’t change the amount of</div>

<div>testing that has to be performed. </div>

<div><br>

</div>

<div>Advantages</div>

<div><br>

</div>

<div>- Straightforward and easy to understand.</div>

<div>- Fully covers clang functionality including interplay between frontend and the</div>

<div>headers. </div>

<div><br>

</div>

<div>Disadvantages</div>

<div><br>

</div>

<div>- A lot of extra testing to maintain.</div>

<div>- Clang testing time increase (see detailed measurements in [7]). </div>

<div><br>

</div>

<div>(2) Combined approach: (a) auto-generate and run tests (b) diff summaries. </div>

<div>This is similar to (1) but instead of committing the large test file into the

</div>

<div>repository it can be auto-generated at each run of check-clang target. After

</div>

<div>test generation from Tablegen invocation, the test will be run regularly </div>

<div>through clang. </div>

<div><br>

</div>

<div>Since both the function declaration and tests are generated from the same </div>

<div>OpenCLBuiltins.td definition and therefore sensitive to errors in the original

</div>

<div>Tablegen description file, we suggest to complement this testing with checking

</div>

<div>in some statistics about each function that can be compared to the output </div>

<div>summary also produced from the Tablegen definitions. This brings the additional

</div>

<div>benefit that not every configuration has to be tested with the full test: </div>

<div>instead, different configurations can be tested using statistics, which would

</div>

<div>bring down the overall testing time. </div>

<div><br>

</div>

<div>Advantages</div>

<div><br>

</div>

<div>- No large checked-in files.</div>

<div>- Easy to modify and maintain.</div>

<div>- Should cover most scenarios where interplay between the frontend and builtin</div>

<div>headers causes issues for OpenCL users. </div>

<div><br>

</div>

<div>Disadvantages</div>

<div><br>

</div>

<div>- Not as straightforward as just checking in a large test file.</div>

<div>- Not giving perfect coverage as there is no way of checking that the Tablegen

</div>

<div>definitions are correct, i.e. subtle errors might slip through, such as for </div>

<div>example changing the argument type of a builtin.</div>

<div>- Clang testing time increases, but less than in (1), because we can rely on the</div>

<div>generated statistics to reduce the amount of tested configurations. </div>

<div><br>

</div>

<div>(3) An alternative approach to avoid parsing large test files and therefore </div>

<div>negatively impacting the testing time is to use the existing opencl-c.h header

</div>

<div>to diff against an auto-generated header that can be produced from the Tablegen

</div>

<div>definition. In this approach the contents of OpenCLBuiltins.td is compared to

</div>

<div>the contents of opencl-c.h by diffing the headers in a pretty-printed format.

</div>

<div>Proof of concept is available in [6]. </div>

<div><br>

</div>

<div>When this test is deployed, both opencl-c.h and OpenCLBuiltins.td will be </div>

<div>incrementally modified keeping the functionality in alignment. </div>

<div><br>

</div>

<div>Advantages </div>

<div><br>

</div>

<div>- No large test files to be checked in or run.</div>

<div>- Diffing is very fast compared to parsing. See details in [8]. </div>

<div><br>

</div>

<div>Disadvantages </div>

<div><br>

</div>

<div>- No coverage through clang invocation. Note that we already test elsewhere </div>

<div>that the basic parsing of the headers succeeds.</div>

<div>- Requires maintaining builtin declarations in two places: the Tablegen definitions</div>

<div>and opencl-c.h. </div>

<div><br>

</div>

<div>=======<br>

</div>

<div>Actions: </div>

<div>=======</div>

<div><br>

</div>

<div>We would like to get feedback from the community regarding whether the </div>

<div>exhaustive testing of the builtins is something that we should try to avoid</div>

<div>(see item (1)). And if so what would be a preferable approach to the testing:</div>

<div>(2) or (3). </div>

<div><br>

</div>

<div>Overall, it would also be possible to look into more hybrid approaches </div>

<div>combining the above alternatives. But it would add extra complexity into </div>

<div>testing that we would like to avoid unless it’s necessary. </div>

<div><br>

</div>

<div>If there are similar situations in other areas it would be good to understand

</div>

<div>whether we could look into more generalized solutions to such testing in clang

</div>

<div>or even wider in llvm-project.</div>

<div><br>

</div>

<div>=========<br>

</div>

<div>References:</div>

<div>=========<br>

</div>

<div><br>

</div>

<div>[1] www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#built-in-functions</div>

<div>[2] llvm.org/devmtg/2019-10/talk-abstracts.html#lit5</div>

<div>[3] clang.llvm.org/docs/OpenCLSupport.html#opencl-builtins</div>

<div>[4] lists.llvm.org/pipermail/cfe-dev/2021-February/067610.html</div>

<div>[5] reviews.llvm.org/D97869</div>

<div>[6] reviews.llvm.org/D99577</div>

<div>[7] reviews.llvm.org/D97869#2648821</div>

<div>[8] reviews.llvm.org/D99577#2663201 <br>

</div>

</div>

</body>

</html>