Re: rapidfuzz failing 9.0 i386 2023Q2

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: Mon, 3 Jul 2023 12:16:38 +0000
> From: Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>
> 
> > Date: Mon, 03 Jul 2023 08:05:03 -0400
> > From: Greg Troxel <gdt%lexort.com@localhost>
> > 
> > But, I am thinking that we should just drop i386 from the avx2
> > conditional for PLIST.  I think it's only there because when fixing this
> > for "not x86" there was an assumption these files were generated on
> > "x86", rather than "architectures for which avx2 is guaranteed, meaning
> > x86_64".
> 
> Now, if there's hand-written amd64 assembly that uses 64-bit general
> instructions as well as AVX2 instructions, yes, that won't work when
> MACHINE_ARCH is i386 -- but a priori, i386 does not imply no-AVX2.

I took a quick look, and it seems that:

1. All of the AVX2 code in rapidfuzz is done with compiler intrinsics,
   so there's a good chance it will just work out of the box on `i386'
   (i.e., sufficiently recent x86 CPUs with AVX2 support, which are
   running in 32-bit mode, sometimes also called ia32 to reduce
   confusion with the decades-old i386 CPU model).

2. There's some CPUID detection logic, so it probably isn't a problem
   to bake it in at compile-time.

3. There's CMakeLists.txt crud to exclude this according to
   `check_cpu_arch_x64' (meaning amd64) which should probably be a
   combination of that and `check_cpu_arch_x86' (meaning ia32) unless
   is actually something amd64-specific here.

Of course, it is also possible that the code just doesn't work in
32-bit mode.  But there appear to be automatic tests, so that should
be quick to check.