On Tue, Aug 02, 2022 at 03:55:39PM -0700, Andres Freund wrote: > FWIW, I'd split the introduction of the helper and the use of it in snapmgr > into separate patches.
Will do. > On 2022-08-02 15:13:01 -0700, Nathan Bossart wrote: >> diff --git a/src/include/c.h b/src/include/c.h >> index d35405f191..2c1a47bc28 100644 >> --- a/src/include/c.h >> +++ b/src/include/c.h >> @@ -371,6 +371,14 @@ typedef void (*pg_funcptr_t) (void); >> #endif >> #endif >> >> +/* >> + * Are SSE2 intrinsics available? >> + */ >> +#if (defined(__x86_64__) || defined(_M_AMD64)) >> +#include <emmintrin.h> >> +#define USE_SSE2 >> +#endif >> + > > It doesn't strike me as a good idea to include this in every single > translation unit in pg. That header (+dependencies) isn't small. > > I'm on board with normalizing defines for SSE availability somewhere central > though. Yeah, this is just a temporary hack for now. It'll go away once the defines for SSE2 availability are committed. >> +/* >> + * pg_linearsearch_uint32 >> + * >> + * Returns the address of the first element in 'base' that equals 'key', or >> + * NULL if no match is found. >> + */ >> +#ifdef USE_SSE2 >> +pg_attribute_no_sanitize_alignment() >> +#endif > > What's the deal with this annotation? Needs a comment. Will do. c.h suggests that this should only be used for x86-specific code. >> +static inline uint32 * >> +pg_linearsearch_uint32(uint32 key, uint32 *base, uint32 nelem) > > Hm. I suspect this could be a bit faster if we didn't search for the offset, > but just for presence in the array? Most users don't need the offset. Just under half of the callers in 0002 require the offset, but I don't know if any of those are worth optimizing in the first place. I'll change it for now. It's easy enough to add it back in the future if required. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com