[libc-commits] [PATCH] D139839: [libc] Add a loader utility for AMDHSA architectures for testing

[Siva Chandra via Phabricator via libc-commits]

sivachandra added a comment.

In D139839#3991577 <https://reviews.llvm.org/D139839#3991577>, @JonChesterfield wrote:

> Hi sivachandra. Integration tests might be the right terminology here. The idea is to take a self contained program containing int main(), compile it for the GPU, then run it using as little infra as possible to minimise the number of places to look for bugs when it goes wrong. The same test would compile and run unchanged on the host architecture, or through qemu or similar if an emulator is available.

This is exactly what the libc integration tests do. They are built as the smallest self-contained exe containing pieces only from LLVM's libc and executed. For each integration test, we build a libc containing only the functions that are required for the test and link the test exe against that minimal libc. Effectively, the integration tests do not link against the entire libc.

> That main() could contain a bunch of unit tests, given a framework that can run without dependencies that we don't have yet (so no ostream, at least until a libc++ on the GPU is a thing), but in the first instance it probably streams data to various libc functions directly and returns non-zero if something unexpected happens.

Again, this is exactly what we do in the libc unit tests. Take a look at an example: https://github.com/llvm/llvm-project/blob/main/libc/test/integration/src/stdlib/getenv_test.cpp#L30. We use a `TEST_MAIN` macro which is just a short hand for `extern "C" int main`: https://github.com/llvm/llvm-project/blob/main/libc/utils/IntegrationTest/test.h#L69

For the GPU, one will have to implement the equivalents of `__llvm_libc::write_to_stderr` and `__llvm_libc::quick_exit` that are used here: https://github.com/llvm/llvm-project/blob/main/libc/utils/IntegrationTest/test.h#L69. Likely, a `gpu` directory should be added here and those implementation should live in that directory: https://github.com/llvm/llvm-project/tree/main/libc/src/__support/OSUtil/linux

> I'd be especially pleased to have this sort of run main() infra in tree as it would let us add other functional testing to the GPU later, e.g. checking that the backend computes the right values under diff optimisation levels, or driving individual pieces of higher level language runtimes. So in a perfect world the loader machinery might end up in some utility folder outside of libc, but this is a great place to stand it up.

I don't see any problems including the loader system in the libc part of the tree.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139839/new/

https://reviews.llvm.org/D139839