[PATCH] D101681: [Compiler-rt] Distinguish between testing just built runtime libraries and the libraries shipped with the compiler.

Dan Liew via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 30 17:17:53 PDT 2021


delcypher created this revision.
delcypher added reviewers: mstorsjo, phosek, thakis, vitalybuka, yln, aralisza, kubamracek.
Herald added subscribers: yaxunl, mgorny, dberris.
delcypher requested review of this revision.
Herald added a project: Sanitizers.
Herald added a subscriber: Sanitizers.

The path to the runtime libraries used by the compiler under test
is normally identical to the path where just built libraries are
created. However, this is not necessarily the case when doing standalone
builds. This is because the external compiler used by tests may choose
to get its runtime libraries from somewhere else.

When doing standalone builds there are two types of testing we could be
doing:

- Test the just built runtime libraries.
- Test the runtime libraries shipped with the compile under test.

Both types of testing are valid but it confusingly turns out compiler-rt
actually did a mixture of these types of testing.

- The `test/builtins/Unit/` test suite always tested the just built runtime libraries.
- All other testsuites implicitly use whatever runtime library the compiler decides to link.

There is no way for us to infer which type of testing the developer
wants so this patch introduces a new `COMPILER_RT_TEST_BUILT_LIBS` CMake
option which explicitly declares which runtime libraries should be
tested. If it is `ON` then the just built libraries should be tested,
otherwise the libraries in the external compiler should be tested.

When testing starts the lit test suite queries the compiler used for
testing to see where it will get its runtime libraries from.  If these
paths are identical no action is taken (the common case). If the paths
are not identical then we check the value of
`COMPILER_RT_TEST_BUILT_LIBS` (progated into the config as
`test_built_libs`) and check if the test suite supports testing in the
requested configuration.

- If we want to test just built libs and the test suite supports it (currently only `test/builtins/Unit`) then testing proceeds without any changes.
- If we want to test the just built libs and the test suite doesn't support it we emit a fatal error to prevent the developer from testing the wrong runtime libraries.
- If we are testing the compiler's built libs then we adjust `config.compiler_rt_libdir` to point at the compiler's runtime directory. This makes the `test/builtins/Unit` tests use the compiler's builtin library. No other changes are required because all other testsuites implicitly use the compiler's built libs.

To make the above work the `test_suite_supports_testing_built_libs`
test suite config option has been introduced so we can identify
what each test suite supports.

Note all of these checks **have to be performed** when lit runs.
We cannot run the checks at CMake generation time because
multi-configuration build systems prevent us from knowing what the
paths will be.

Currently this patch only changes the behavior for Darwin when Clang is
used as the compiler but it should be possible to support other host
platforms that use Clang. Unfortunately `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`
will complicate things here so it is probably best we handle that
in a separate patch.

We could perhaps support `COMPILER_RT_TEST_BUILT_LIBS` being `ON`
for most test suites in the future by specifiying a custom compiler
resource directory path. Doing so is out of scope for this patch.

rdar://77182297


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101681

Files:
  compiler-rt/test/CMakeLists.txt
  compiler-rt/test/builtins/Unit/lit.site.cfg.py.in
  compiler-rt/test/lit.common.cfg.py
  compiler-rt/test/lit.common.configured.in

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D101681.342093.patch
Type: text/x-patch
Size: 5349 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210501/67efa764/attachment.bin>


More information about the llvm-commits mailing list