Re: always use runtime checks for CRC-32C instructions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: always use runtime checks for CRC-32C instructions
Date
Msg-id 2620794.1698783160@sss.pgh.pa.us
Whole thread Raw
In response to Re: always use runtime checks for CRC-32C instructions  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: always use runtime checks for CRC-32C instructions
List pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> Okay.  With that in mind, I think the path forward for new instructions is
> as follows:

> * If the special CRC instructions can be used with the default compiler
>   flags, we can only use newer instructions if they can also be used with
>   the default compiler flags.  (My M2 machine appears to add +crypto by
>   default, so I bet your buildfarm animals would fall into this bucket.)
> * Otherwise, if the CRC instructions can be used with added flags (i.e.,
>   the runtime check path), we can do a runtime check for the new
>   instructions as well.  (Most other buildfarm animals would fall into this
>   bucket.)

This seems like a reasonable proposal.

> Any platform that can use the CRC instructions with default compiler flags
> but not the new instructions wouldn't be able to take advantage of the
> proposed optimization, but it also wouldn't be subject to the small
> performance regression.

Check.  For now I think that's fine.  If we get to a place where this
policy is really leaving a lot of performance on the table, we can
revisit it ... but that situation is hypothetical and may remain so.

(It's worth noting also that a package builder can move the goalposts
at will, since our idea of "default flags" is really whatever the user
says to use.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Tristan Partin"
Date:
Subject: Re: Use thread-safe locale APIs
Next
From: Nathan Bossart
Date:
Subject: Re: always use runtime checks for CRC-32C instructions