<div dir="ltr"><div>Will building with x86-64-v2 and higher happen automatically in bullseye?<br></div><div><br></div><div>Or will it become policy to accept the introduction of  -march=x86-64-v[234] in the compiler flags?<br></div><div><br></div><div>If so, for SIMDe-using packages[0] we would then need to detect the presence of  -march=x86-64-v? in the *FLAGS and disable building multiple versions of the binaries as we currently do manually in each packages 'debian/rules/<br></div><div><br></div><div>[0] <a href="https://wiki.debian.org/SIMDEverywhere#Packages_Status">https://wiki.debian.org/SIMDEverywhere#Packages_Status</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 21, 2021 at 6:48 PM Étienne Mollier <<a href="mailto:emollier@emlwks999.eu">emollier@emlwks999.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Control: tag -1 confirmed<br>
<br>
Good day,<br>
<br>
having a closer look at kmc, there is simde set up, and it looks<br>
like enabling -march=x86-64-v2 leads through a buggy build path.<br>
Some parts of the source code are designed to build against some<br>
specific combinations of machine specific flags.  In the present<br>
case, if I inject -march=x86-64-v2, and some diagnostic output,<br>
then a mismatch appears between code targetting the specific cpu<br>
capability sse2, caused by availability of sse4.1 in build<br>
options:<br>
                                                  vvvv<br>
        In file included from kmer_counter/raduls_sse2.cpp:12:<br>
        kmer_counter/raduls_impl.h:734:2: warning: #warning "RADULS_RADIX_SORT_FUNNAME=RadixSortMSD_SSE41" [-Wcpp]<br>
                                                                                                    ^^^^^<br>
thus, explaining the error reported by Matthias:<br>
> ./kmer_counter/kmc.h:1132: undefined reference to `void RadulsSort::RadixSortMSD_SSE2<CKmer<2u> >(CKmer<2u>*, CKmer<2u>*, unsigned long long, unsigned int, unsigned int, CMemoryPool*)'<br>
> collect2: error: ld returned 1 exit status<br>
<br>
To a larger extent, this is bound to fail with additional<br>
symptoms when using machine types x86-64-v3, as it appends<br>
various avx support, without mentionning various combinations<br>
thrown by -march=native.  I see two options to mitigate this:<br>
 1. either disable build of raduls_sse2.cpp, which is unneeded<br>
    in x86-64-v2 context, since it is overred by the sse4.1<br>
    implementation raduls_sse41.cpp any ways;<br>
 2. or cheat with the C preprocessor macro definitions, to get<br>
    back the missing function in its sse2 only context.<br>
<br>
Point 1 looks cleaner to me, but I only have been able to<br>
implement point 2 successfully so far, without causing baseline<br>
violations in normal builds, nor beating the purpose of<br>
optimisations, and with support for further flags combinations<br>
than just the baseline or -march=x86-64-v2.  Will push changes<br>
on Salsa this evening, most likely.<br>
<br>
Have a nice day,  :)<br>
-- <br>
Étienne Mollier <<a href="mailto:emollier@emlwks999.eu" target="_blank">emollier@emlwks999.eu</a>><br>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da<br>
Sent from /dev/pts/6, please excuse my verbosity.<br>
_______________________________________________<br>
Debian-med-packaging mailing list<br>
<a href="mailto:Debian-med-packaging@alioth-lists.debian.net" target="_blank">Debian-med-packaging@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging</a><br>
</blockquote></div>