osmo-trx: different output in convolve test between x86 vs neon vs neon-vfpv4
I attach the output while running convolve_test (previously in utils/ directory) on a x86 with ssse3 and sse4.1. Now that I am implementing the infrastructure to run tests in ARM (see #2721), I found out that the output for this test is different in neon and neon-vfpv4 cases. The output is also different between the 2 neon ones. The arm testsuite.log files contains the diff aginst the x86 one (as it was the first one I used and the tool was initially wrote against it, it's the "expected" output").
I don't know if that's expected or if it's actually a bug. Assigning to Tom as he seems to be the one knowing more about this topic and who wrote the initial code for ARM.
#3 Updated by ttsou almost 3 years ago
I still need to look into the specific numbers as well as reproduce the issue locally, however, I suspect the issue relates to IEEE-754 floating point conformance.
The ARMv7 NEON instruction set is not IEEE-754 compliant, which can very well lead to inconsistent floating point output across builds.
An interesting question would be if the test fails on ARMv8 where the NEON instruction set is IEEE-754 compliant.
I will have more details shortly.
#4 Updated by pespin almost 3 years ago
Thanks for looking into it. If you have time and didn't see it yet, please read https://lists.osmocom.org/pipermail/openbsc/2018-January/011655.html
#8 Updated by tnt almost 2 years ago
- Status changed from New to In Progress
Looking at that now ...
I mean direct exact text compare for such kind of test is never going to work because of the IEEE precision ... sometimes because of non-perfect compliant operation, or because we purposefully do a faster less precise operation, or because operations in different orders, ... and so in either case you convole_test should have the test vector and expected results built-in and do the compare internally tolerating small deltas (sometime like X% deviation + a small epsilon).
But looking at the logs posted, some of the deviations seems a bit large, so I'll be checking that first.
#9 Updated by tnt almost 2 years ago
- Removed unused / unsupported features from the codebase
- Reworked the convole_test utility to be more useful and consistent across platform
- That new test utility actually uncovered a bug in the neon vfp4 implementation, so fixed that.
- Re-enabled convolve_test by default.
All pushed on gerrit for review.