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