Re: Not-terribly-safe checks for CRC intrinsic support

+# is missing, we must link not just compile, and store the results in 
global

The "compile" should be "compiler"?

Regards,
Steven

在 2025/3/15 7:04, Tom Lane 写道:
> I noticed that our configuration-time checks for the presence
> of CRC intrinsics generally look like
> 
>      unsigned int crc = 0;
>      crc = __crc32cb(crc, 0);
>      crc = __crc32ch(crc, 0);
>      crc = __crc32cw(crc, 0);
>      crc = __crc32cd(crc, 0);
>      /* return computed value, to prevent the above being optimized away */
>      return crc == 0;
> 
> The trouble with this is that "crc" is a local variable, so the
> compiler would be perfectly within its rights to optimize the whole
> thing down to "return some_constant".  While that outcome sufficiently
> proves that the compiler has heard of these intrinsics, it fails to
> prove that the platform has any necessary library infrastructure,
> assembler support for the opcodes, etc etc.  Whoever originally
> wrote this evidently had concern for that hazard, or they'd not
> have bothered with forcing a dependency on the final value; but
> that seems insufficient.  We have other nearby tests that try
> to avoid this problem by making the functions-under-test operate
> on global variables, so I think we should do likewise here.
> 
> In connection with bug #18839[1], I checked to see if this might
> already be happening.  At least with gcc 12.2 on armhf Debian,
> it doesn't seem to: the compiler still generates the crc opcodes.
> But the same compiler is perfectly willing to optimize a call to
> sin(3) down to a constant under similar conditions.  So I think this
> is just a matter of they didn't get round to it, not that there's a
> principled reason to think they won't ever get round to it.  There
> might be other cases where these probes are already missing something,
> and we've not noticed because there's-compiler-support-but-no-
> library-support is surely a very rare case in the field.
> 
> In short, I think we ought to apply and perhaps back-patch something
> like the attached.
> 
> 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.
> 
> Thoughts?
> 
>             regards, tom lane
> 
> [1] https://www.postgresql.org/message-id/18839-7615d0f8267dc015%40postgresql.org
>