Date: Thu, 7 Nov 2024 09:28:44 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <hlinnaka@iki.fi>,
	Bastien =?iso-8859-1?Q?Roucari=E8s?= <rouca@debian.org>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: Detection of hadware feature => please do not use signal
Message-ID: <ZyzcrD2GsvIFrDdO@nathan>
References: <4496616.iHFcN1HehY@portable-bastien>
 <af84e934-4e9c-4380-95ee-8921dab1254b@iki.fi>
 <1156374.1730396928@sss.pgh.pa.us>
 <7ec1c65c-1a28-49a7-af43-f77c260a3df6@iki.fi>
 <1292593.1730399134@sss.pgh.pa.us>
 <CA+hUKGLRXq0-s0n2=dy_A5iY-Omg628osyJEJMjPQ=6m566UgA@mail.gmail.com>
 <1624905.1730436275@sss.pgh.pa.us>
 <1637254.1730441792@sss.pgh.pa.us>
 <CA+hUKGKvZ7eyMOCt-k=Ezuvn6GLR9fFSLRFYA666OFMnK2kgTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+hUKGKvZ7eyMOCt-k=Ezuvn6GLR9fFSLRFYA666OFMnK2kgTQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZyzcrD2GsvIFrDdO%40nathan>
Precedence: bulk

On Sat, Nov 02, 2024 at 06:11:33PM +1300, Thomas Munro wrote:
> On Fri, Nov 1, 2024 at 7:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Actually, after chewing on that second point awhile longer,
>> how about this modest proposal:
>>
>> * Drop all code for run-time determination of ARM CRC support.
>> Assume it's there unless user builds with a -march option that
>> says it definitely isn't.
> 
> For CRC32, that would work (and already does via configure tests) for
> macOS (I'd forgotten about that in my earlier message, Macs never even
> compile the CRC32 "choose" code because the system compiler targets M1
> by default), recent RHEL (see below), and presumably others, but it
> would penalise Debian, FreeBSD (using the standard binary package
> repo) and others if we didn't have the runtime check due to their
> conservative choice of baseline arch (as Bastien just said about
> Debian in a crossed email).  I've been wondering about what to do
> about all this for a while...  There are also other features we aren't
> using yet, but should, or single instructions that we are calling
> through function pointers, preventing automatic vectorisation etc.

One small improvement in this area that I'm working on (and about to commit
for the AVX-512 stuff) is using __attribute__((target(...))) instead of
special -march options for specific files [0].  Among other things, this
simplifies the configure checks and eliminates the need to put chunks of
code in separate files.  However, I found that until recently, it wasn't
possible to include arm_acle.h without the -march flag [1], which means we
likely won't be able to make the switch for the ARM CRC stuff for a few
more years.

More to the point, until the baseline moves, I think we'll end up adding
checks in header files so that we only take the function pointer overhead
when it's likely to be worth it (e.g., pg_popcount() in pg_bitutils.h).  It
might be worth doing that for the CRC-32C code, too, since we are still
quite reliant on the runtime check.

[0] https://commitfest.postgresql.org/50/5305/
[1] https://postgr.es/m/ZwXsE0KG_wh6_heU%40nathan

-- 
nathan