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