[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