[cfe-dev] [RFC][OpenCL] Testing all OpenCL builtin function declarations in clang
Anastasia Stulova via cfe-dev
cfe-dev at lists.llvm.org
Mon Apr 19 03:31:39 PDT 2021
I would like to summarise the offline discussion among OpenCL developers
regarding the testing strategies that we have chosen to implement:
- We will go ahead with option (2) i.e. automatic generation of tests and use
of clang invocation originally proposed in reviews.llvm.org/D97869 for the fast
header mechanism based on the Tablegen definitions.
- We will enhance the testing with test files added and maintained manually
that will be checking the statistical information as explained in (2) or also
the comparison between opencl-c.h and Tablegen description (3). The latter one
(originally proposed in reviews.llvm.org/D99577) could also be useful to obtain
additional coverage for opencl-c.h testing if there is enough interest while it
is still in maintenance.
Let me know if there is any feedback on the proposed plan.
From: Anastasia Stulova
Sent: 06 April 2021 18:23
To: clang developer list <cfe-dev at lists.llvm.org>
Cc: Sven Van Haastregt <Sven.VanHaastregt at arm.com>; Zabaznov, Anton <anton.zabaznov at intel.com>
Subject: [RFC][OpenCL] Testing all OpenCL builtin function declarations in clang
We would like to ask for feedback regarding testing strategies for the large
amount of OpenCL builtin function declarations.
The OpenCL standard has many builtin functions  implicitly declared during
the kernel compilation. The regular opencl-c.h header in clang containing all
declarations is nearly 17K lines and it is therefore very expensive in terms of
compilation time to include. This has caused issues with its testing because
clang-check testing time is affected. This is one of the main reasons it has
been tested very sparsely (~150 lines of tests) so far in llvm-project. The full
functionality is being tested outside of llvm-project in various vendor and
open-source tooling projects. However, it doesn’t help to detect issues during
development cycles in llvm-project.
In the meantime we have developed a new mechanism to implicitly include the
function declarations leveraging Tablegen that addressed parsing speed
and other limitations. However, the testing has still remained sparse due to the
time considerations. This proposal is addressing testing limitations of OpenCL
builtin functions declared via Tablegen approach and it is based on the detailed
discussions in . Below we present a summary of some options that we have
found promising and invite for feedback to help us define the directions.
(1) Standard testing via clang invocation and use of -verify.
This is a regular straightforward format of testing that aims at checking that
headers can be parsed for various configurations. Similar tests are already part
of clang test suite, e.g. Headers/arm-neon-header.c or
In contrast for our case we would like to call each overload of builtin functions to
verify the right functionality is exposed through the header. The tests could be
written manually from scratch or auto-generated initially and then manually
evolved/maintained. It is expected that the test file will be quite large - the
auto-generated version currently has about 60K lines (see details in ). For
comparison, the largest test file in clang is currently around 20K lines. It is
possible to partition into multiple test files but it doesn’t change the amount of
testing that has to be performed.
- Straightforward and easy to understand.
- Fully covers clang functionality including interplay between frontend and the
- A lot of extra testing to maintain.
- Clang testing time increase (see detailed measurements in ).
(2) Combined approach: (a) auto-generate and run tests (b) diff summaries.
This is similar to (1) but instead of committing the large test file into the
repository it can be auto-generated at each run of check-clang target. After
test generation from Tablegen invocation, the test will be run regularly
Since both the function declaration and tests are generated from the same
OpenCLBuiltins.td definition and therefore sensitive to errors in the original
Tablegen description file, we suggest to complement this testing with checking
in some statistics about each function that can be compared to the output
summary also produced from the Tablegen definitions. This brings the additional
benefit that not every configuration has to be tested with the full test:
instead, different configurations can be tested using statistics, which would
bring down the overall testing time.
- No large checked-in files.
- Easy to modify and maintain.
- Should cover most scenarios where interplay between the frontend and builtin
headers causes issues for OpenCL users.
- Not as straightforward as just checking in a large test file.
- Not giving perfect coverage as there is no way of checking that the Tablegen
definitions are correct, i.e. subtle errors might slip through, such as for
example changing the argument type of a builtin.
- Clang testing time increases, but less than in (1), because we can rely on the
generated statistics to reduce the amount of tested configurations.
(3) An alternative approach to avoid parsing large test files and therefore
negatively impacting the testing time is to use the existing opencl-c.h header
to diff against an auto-generated header that can be produced from the Tablegen
definition. In this approach the contents of OpenCLBuiltins.td is compared to
the contents of opencl-c.h by diffing the headers in a pretty-printed format.
Proof of concept is available in .
When this test is deployed, both opencl-c.h and OpenCLBuiltins.td will be
incrementally modified keeping the functionality in alignment.
- No large test files to be checked in or run.
- Diffing is very fast compared to parsing. See details in .
- No coverage through clang invocation. Note that we already test elsewhere
that the basic parsing of the headers succeeds.
- Requires maintaining builtin declarations in two places: the Tablegen definitions
We would like to get feedback from the community regarding whether the
exhaustive testing of the builtins is something that we should try to avoid
(see item (1)). And if so what would be a preferable approach to the testing:
(2) or (3).
Overall, it would also be possible to look into more hybrid approaches
combining the above alternatives. But it would add extra complexity into
testing that we would like to avoid unless it’s necessary.
If there are similar situations in other areas it would be good to understand
whether we could look into more generalized solutions to such testing in clang
or even wider in llvm-project.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev