tree 637f140a85b98c6d63605b82752abb8181a43d51
parent 8199f3b3218a931cd0a165440b0d99472f4697a4
author Scott Todd <scotttodd@google.com> 1641487278 -0800
committer GitHub <noreply@github.com> 1641487278 -0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJh1xuuCRBK7hj4Ov3rIwAAWBUIAJ7vmQCv75hVFIV3saaE8SzS
 RwS5bpmvsbuh4xm3qSUCF2Hux2Ee3zonop7a+UOovrs0Ert6I6+l0VJaceAsIUrp
 O1b8nT68PBZw5k5FH2/wWLOsJau0XW6fCsP7Tfw9aKhhJd5G6Zf/qwp5TRTc7zx4
 XAAJksUcMovgPJ7FFVXReT2GFOZnydkfkglABRG6cRDMvLbkPTH04VYJG8cpazCc
 HU3KhTB8VON6zf+ZBeY10Ztd+q2YH3ln+TaFmncGTMm0IKQJYxaSpSgXqAN27juE
 8ThSqjRvBNLPIKeDLLqk+4OdUXh+ko11yWz4Ca8B9snPYu0FUKO6+uX8jMEX5sE=
 =EZIf
 -----END PGP SIGNATURE-----
 

Add HAL CTS tests using executables. (#7982)

Fixes https://github.com/google/iree/issues/5678 (for `executable_cache_test`, tests issuing dispatches can follow on later)

Tests are filtered based on the HAL driver and compiler target being enabled as well as the presence of a new `COMPILER_TARGET_BACKEND` parameter to the `iree_hal_cts_test_suite()` function.

If all of those conditions are met, executable testdata is generated using the new `-iree-mlir-to-hal-executable` translation mode and relevant tests in the suite get to load and reference the generated data.

---

Rough edges:

* ~~`iree_file_toc_t` definition copy/paste from `generate_embed_data` (since leaf binaries provide their own implementations)~~
* Specifying executable formats in CMake is hacky (`"\"embedded-elf-\" IREE_ARCH"`)
* We may also want to test the system loader as well as the embedded loader, which is possible with another `iree_hal_cts_test_suite()` call

I was also expecting the CMake to be a bit gnarly, and it is. Could maybe refactor into some helper functions or golf on the logic a bit. The interface to each HAL implementation is pretty nice, but the new implicit dependency on `iree-translate` makes it harder to use with out-of-tree runtime HAL drivers + compiler targets. Could pass `TRANSLATE_TOOL` as well 🤔