[clang] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h conflicts (PR #115099)

Eli Friedman via cfe-commits cfe-commits at lists.llvm.org
Mon Feb 3 13:50:53 PST 2025


================
@@ -146,8 +146,13 @@ let Attributes = [Const, NoThrow, RequiredVectorWidth<256>], Features = "avx" in
 // current formulation is based on what was easiest to recognize from the
 // pre-TableGen version.
 
-let Features = "mmx", Attributes = [NoThrow, Const] in {
-  def _mm_prefetch : X86NoPrefixBuiltin<"void(char const *, int)">;
+let Features = "mmx", Header = "immintrin.h", Attributes = [NoThrow, Const] in {
+  def _mm_prefetch : X86LibBuiltin<"void(void const *, int)">;
+}
+
+let Features = "mmx", Header = "intrin.h", Attributes = [NoThrow, Const] in {
+  def _m_prefetch : X86LibBuiltin<"void(void *)">;
+  def _m_prefetchw : X86LibBuiltin<"void(void volatile const *)">;
----------------
efriedma-quic wrote:

The whole thing is sort of confusing...

AMD originally implemented 3dnow including prefetch and prefetchw instructions.  Intel then implemented SSE with different prefetch instructions... but didn't include one with a write hint.  Later, they implemented prefetchw, and added a corresponding CPUID bit.

Modern LLVM never generates "prefetch"; _m_prefetch is actually lowered to the SSE prefetcht0.

`_mm_prefetch(x, _MM_HINT_ET0)` generates different instructions depending on the command-line: if the target only supports SSE, it generates prefetcht0.  If it supports prefetchw (`-mprfchw`), it generates prefetchw.

I guess given that behavior, this feature mapping is probably fine?

https://github.com/llvm/llvm-project/pull/115099


More information about the cfe-commits mailing list