[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