Re: Not-terribly-safe checks for CRC intrinsic support - Mailing list pgsql-hackers

From John Naylor
Subject Re: Not-terribly-safe checks for CRC intrinsic support
Date
Msg-id CANWCAZapfYkk+vqF+qeomOE7-0uFbPRJ=U=n3ghMxF_4-gAkCQ@mail.gmail.com
Whole thread Raw
In response to Not-terribly-safe checks for CRC intrinsic support  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Not-terribly-safe checks for CRC intrinsic support
List pgsql-hackers
On Sat, Mar 15, 2025 at 6:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> In short, I think we ought to apply and perhaps back-patch something
> like the attached.

Seems like reasonable defensive coding and consistency.

-    /* return computed value, to prevent the above being optimized away */
+    /* else this function could get optimized away altogether: */

-    /* return computed value, to prevent the above being optimized away */
+    /* return computed value, just to be extra sure this isn't
optimized away */

I'd be okay with keeping the original comment, though, since it seems
to be explaining the choice well enough.

> BTW, it looks to me like PGAC_AVX512_POPCNT_INTRINSICS is at similar
> hazard, but I'm not entirely sure how to fix that one.

"buf" is the variable there that we're loading from, so that would be
the one to make global.

--
John Naylor
Amazon Web Services



pgsql-hackers by date:

Previous
From: Daniil Davydov
Date:
Subject: Re: Forbid to DROP temp tables of other sessions
Next
From: Steven Niu
Date:
Subject: Re: Forbid to DROP temp tables of other sessions