You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The AVX2 unit tests are still disabled (in tests/CMakeLists.txt). Ideally, I think we want to use the new CPU feature-detection logic in blosc along with CMake to determine which features the host CPU supports and enable the unit tests accordingly. E.g., if the host supports SSE2 and AVX2, both of those test suites will be enabled within the CMake script itself; if a host doesn't support AVX2 (for example), the tests wouldn't be enabled by CMake and therefore wouldn't even run.
Alternatively, we could use the CPU feature detection within the test programs themselves to determine if the host CPU supports the features necessary for the test to run. In the case where it doesn't, we'd just return a success code (which is what the AVX2 tests are currently doing). Or, instead of returning a success code, it would be better if CMake / CTest supported returning an exit code indicating the test was "ignored" (many of the xUnit-style testing frameworks include this); I don't know whether CTest supports this, so some research would be required.
Any solution implemented for this should be designed under the assumption blosc will support additional CPU feature sets in the future (i.e., not limited to SSE2 and AVX2).
The text was updated successfully, but these errors were encountered:
Provided how complex is getting the code in CMake config files, I would go with using the CPU feature detection right on the test programs. It would be great if CMake / CTes would support the "ignored" flag.
And definitely, the solution would not be limited to the SSE2 and AVX2 (I have plans to create an ARM/ NEON extension as well).
After a bit of research, it looks like CMake allows the SKIP_RETURN_CODE property to be defined for a test; if the test binary returns with that exit code, the test is considered 'skipped'. The easiest way to implement this will likely be to set some CMake variable to the desired "skipped" exit code, then use that variable to set both the property on the tests and to define an EXIT_SKIPPED preprocessor symbol (defined to that value) for use within the test code. GNU autotools uses ``77` as the "skipped" exit code, and it seems most people using this CMake behavior are using the same value for compatibility.
Unfortunately, it looks like there is an issue with the implementation of this feature affecting all versions of CMake up to and including the current version where skipping tests this way causes ctest to return with a non-zero exit code (which would cause our CI builds to fail): http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/12624
It does look like there are some alternative ways to implement this, so I'll keep looking for a workable solution.
The AVX2 unit tests are still disabled (in
tests/CMakeLists.txt
). Ideally, I think we want to use the new CPU feature-detection logic in blosc along with CMake to determine which features the host CPU supports and enable the unit tests accordingly. E.g., if the host supports SSE2 and AVX2, both of those test suites will be enabled within the CMake script itself; if a host doesn't support AVX2 (for example), the tests wouldn't be enabled by CMake and therefore wouldn't even run.Alternatively, we could use the CPU feature detection within the test programs themselves to determine if the host CPU supports the features necessary for the test to run. In the case where it doesn't, we'd just return a success code (which is what the AVX2 tests are currently doing). Or, instead of returning a success code, it would be better if CMake / CTest supported returning an exit code indicating the test was "ignored" (many of the xUnit-style testing frameworks include this); I don't know whether CTest supports this, so some research would be required.
Any solution implemented for this should be designed under the assumption blosc will support additional CPU feature sets in the future (i.e., not limited to SSE2 and AVX2).
The text was updated successfully, but these errors were encountered: