Re: autovectorize page checksum code included elsewhere

On Sat, Nov 25, 2023 at 02:09:14PM +0700, John Naylor wrote:
> On Thu, Nov 23, 2023 at 11:51 PM Nathan Bossart
> <nathandbossart@gmail.com> wrote:
>>
>> On Thu, Nov 23, 2023 at 05:50:48PM +0700, John Naylor wrote:
>> > On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> >> One half-formed idea I have is to introduce some sort of ./configure flag
>> >> that enables all the newer instructions that your CPU understands.
>> >
>> > That's not doable,
>>
>> It's not?
> 
> What exactly would our build system do differently with e.g.
> "-march=native" (which is already possible for people who compile
> their own binaries, via CFLAGS), if I understand you correctly?

It would probably just be an easier way of doing that than adjusting COPT
in src/Makefile.custom.

>> Maybe we have something like --with-isa-level where you can specify
>> x86-64-v[1-4] or "auto" to mean "build whatever the current machine can
>> handle."
> 
> That could work, but with the below OS's, it should work
> automatically. Also, we may not be many years off from the day we can
> move our baseline as well, such that older buildfarm members (if we
> have any) would need to pass --disable-isa-extensions, but that may be
> pushing things too much for too little benefit. *

You are probably right.  I guess I'm wondering whether we need to make all
this configurable.  Maybe we could get away with moving our baseline to v2
soon, but if we'd also like to start adding AVX2 enhancements (and I think
we will), I'm assuming we'll want to provide an easy way for users to
declare that they are building for v3+ CPUs.

>> > Not sure how to detect that easily.
>>
>> I briefly looked around and didn't see a portable way to do so.  We might
>> have to exhaustively check the features, which doesn't seem like it'd be
>> too bad for x86_64, but I haven't looked too closely at other
>> architectures.
> 
> Sorry, I wasn't clear, I mean: detect that a packager passed
> "-march=x86_64-v2" in the CFLAGS, so that a symbol in header files
> would cause inlining of functions containing certain intrinsics.
> Exhaustively checking features defeats the purpose of having an
> industry-standard shorthand, and says nothing about what the package
> does or does not require of the target machine.

I'm not sure why I thought checking each feature might be necessary.
--with-isa-level could essentially just be an alias for adding all the
CFLAGS for the extensions provided at that level, and --with-isa-level=auto
would just mean -march=native.  With those flags set, the ./configure
checks would succeed with the base set of compiler flags passed in, which
could be used as a heuristic for inlining (like CRC32C does today).

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com