Re: autovectorize page checksum code included elsewhere - Mailing list pgsql-hackers

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?

> > but we should consider taking advantage of
> > x86-64-v2, which RedHat 9 builds with. That would allow inlining CRC
> > and popcount there.
>
> 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. *

> I can imagine packagers requiring v2 these days (it's probably
> worth asking them), and that would not only allow compiling in SSE 4.2 on
> many more machines, but it would also open up a path to supporting
> AVX2/AVX512 and beyond.

A brief look found these OS's are moving / have moved to x86-64-v2:

Redhat 9 [1][2]
OpenSuse ALP [3]
OpenSuse Tumbleweed [4]

Debian considers it a bug if the package fails to build with
x86-64-v2, but they haven't changed their baseline requirement. [5]

> > 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.

* Note: I have seen the threads with the idea of compiling multiple
entire binaries, and switching at postmaster start. I think it's a
good idea, but I also suspect detecting flags from the packager is an
easier intermediate step.

[1]
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
[2] https://access.redhat.com/solutions/6833751
[3] https://news.opensuse.org/2022/09/26/alp-architecture-baselevel-x86_64-v2/
[4] https://news.opensuse.org/2022/11/28/tw-to-roll-out-mitigation-plan-advance-microarchitecture/
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983926