Hi Andreas, Andreas Beckmann, on 2022-09-26: > BTW, the package content should not depend on the build host cpu. > The sid package currently has avx2 binaries, if I rebuild it it gets > avx512 binaries, who knows what happens after a binNMU? This can easily > lead to significant performance regressions for some users. > > As there seems to be some kind of runtime cpu detection, perhaps a > bigger list of cpu targets could be built and shipped (even targets > not supported by the buildd cpu). For correctness validation, > a separate package containing the tests (if any) could be provided...
Focusing on the sid distribution, configure options allow for
disabling simd entirely, enabling them depending on the build
machine, and enforcing a certain baseline with. This is done by
playing with options --disable-simd, --enable-simd, and
--with-simd-level= (which takes said level as argument)
respectively.
Looking at gmap source code, there is support up to avx512bw
intrinsics, but for some reason the build fails when the
underlying CPU of the build machine does not support the host
target. I don't have access to an avx512 capable host right
now, but I can reproduce the build failure with avx2 instead: it
builds fine on my machine, but when I attempt a build on a
generic virtual machine, the same build fails with similar
symptoms:
gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt
-DHAVE_SSE2=1 -DHAVE_SSSE3=1 -DHAVE_SSE4_1=1 -DHAVE_SSE4_2=1 -DHAVE_AVX2=1 -g
-O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat
-Werror=format-security -c -o gmap_avx2-compress.o `test -f 'compress.c' ||
echo './'`compress.c
In file included from compress.c:41:
/usr/lib/gcc/x86_64-linux-gnu/12/include/tmmintrin.h: In function
‘Compress_shift’:
/usr/lib/gcc/x86_64-linux-gnu/12/include/tmmintrin.h:185:1: error:
inlining failed in call to ‘always_inline’ ‘_mm_alignr_epi8’: target specific
option mismatch
185 | _mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N)
| ^~~~~~~~~~~~~~~
compress.c:1261:22: note: called from here
1261 | leftpart = _mm_alignr_epi8(current,prev,12);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/12/include/tmmintrin.h:185:1: error:
inlining failed in call to ‘always_inline’ ‘_mm_alignr_epi8’: target specific
option mismatch
185 | _mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N)
| ^~~~~~~~~~~~~~~
compress.c:1266:23: note: called from here
1266 | rightpart = _mm_alignr_epi8(current,prev,12);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/12/include/tmmintrin.h:185:1: error:
inlining failed in call to ‘always_inline’ ‘_mm_alignr_epi8’: target specific
option mismatch
185 | _mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N)
| ^~~~~~~~~~~~~~~
compress.c:1265:22: note: called from here
1265 | leftpart = _mm_alignr_epi8(current,prev,8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/12/include/tmmintrin.h:185:1: error:
inlining failed in call to ‘always_inline’ ‘_mm_alignr_epi8’: target specific
option mismatch
185 | _mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N)
| ^~~~~~~~~~~~~~~
compress.c:1270:23: note: called from here
1270 | rightpart = _mm_alignr_epi8(current,prev,8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/12/include/tmmintrin.h:185:1: error:
inlining failed in call to ‘always_inline’ ‘_mm_alignr_epi8’: target specific
option mismatch
185 | _mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N)
| ^~~~~~~~~~~~~~~
compress.c:1269:22: note: called from here
1269 | leftpart = _mm_alignr_epi8(current,prev,4);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/12/include/tmmintrin.h:185:1: error:
inlining failed in call to ‘always_inline’ ‘_mm_alignr_epi8’: target specific
option mismatch
185 | _mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N)
| ^~~~~~~~~~~~~~~
compress.c:1274:23: note: called from here
1274 | rightpart = _mm_alignr_epi8(current,prev,4);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Otherwise when running autopkgtest of build artifacts from my
host to the generic processor, there seems to be all the
branching needed for avoiding illegal instruction errors indeed,
so it is a shame not taking advantage of this.
Correct option would be to fix the build error without impeding
the runtime for processors with high baselines. Easy option
would be either disable simd, or to enforce sticking to the
operating system baseline, i.e. sse2. However, you mentioned
the host which has been decommissioned had sse4_2 support, so
maybe a middle ground could be to align with the current
baseline of buildds? I don't know what it is at t time and
whether it could regress, so I'm not entirely sure this is a
good idea neither.
Have a nice day, :)
--
Étienne Mollier <emoll...@emlwks999.eu>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/0, please excuse my verbosity.
On air: Minimum Vital - chanter toujours
signature.asc
Description: PGP signature
