Re: autovectorize page checksum code included elsewhere

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: Ants Aasma <ants(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: autovectorize page checksum code included elsewhere
Date: 2023-11-27 22:26:19
Message-ID: 20231127222619.GC140989@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 27, 2023 at 03:21:53PM -0600, Nathan Bossart wrote:
> On Sat, Nov 25, 2023 at 02:09:14PM +0700, John Naylor wrote:
>> 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).

Or, perhaps you mean removing those ./configure checks completely and
assuming that the compiler knows about the intrinsics required for the
specified ISA level...

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2023-11-27 22:27:58 Re: Dynamically generate a nested JSON file
Previous Message Jeff Davis 2023-11-27 22:21:59 Re: proposal: change behavior on collation version mismatch