[PATCH] D38824: [X86] Synchronize the existing CPU predefined macros with the cases that gcc defines them

Chandler Carruth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 26 13:50:33 PDT 2017


chandlerc added a comment.

So, doing research to understand the impact of this has convinced me we *really* need to stop doing this. Multiple libraries are actually trying to enumerate every CPU that has feature X for some feature X. =[[[ This, combined with the fundamental pattern of defining a precise macro for the CPU, leaves a time bomb where anyone that passes a new CPU to `-march` using some older headers will incorrectly believe features aren't available on *newer* CPUs. =[

Specific examples:
https://github.com/hwoarang/glibc/blob/master/sysdeps/x86/cpu-features.h#L263
https://github.com/boostorg/atomic/blob/boost-1.65.1/include/boost/atomic/detail/caps_gcc_x86.hpp#L30

I think my conclusion is that the best way forward is to officially stop defining CPU-specific macros, but to also continue defining __corei7__ macros on all CPUs newer than that for all time so that old headers using these macros for "feature detection" actually work.

Thoughts?



================
Comment at: lib/Basic/Targets/X86.cpp:835
     defineCPUMacros(Builder, "slm");
+    // gcc also defineds 'silvermont', but we never have. See comment below.
     break;
----------------
RKSimon wrote:
> defines
Nit picking detail: I would also capitalize GCC here and elsewhere.


https://reviews.llvm.org/D38824





More information about the cfe-commits mailing list