> > > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c > > > > index 9e46b7b136f..762ab89fc9e 100644 > > > > --- a/gcc/config/i386/i386.c > > > > +++ b/gcc/config/i386/i386.c > > > > @@ -137,17 +137,22 @@ const struct processor_costs *ix86_cost = NULL; > > > > #define m_CORE2 (HOST_WIDE_INT_1U<<PROCESSOR_CORE2) > > > > #define m_NEHALEM (HOST_WIDE_INT_1U<<PROCESSOR_NEHALEM) > > > > #define m_SANDYBRIDGE (HOST_WIDE_INT_1U<<PROCESSOR_SANDYBRIDGE) > > > > -#define m_HASWELL (HOST_WIDE_INT_1U<<PROCESSOR_HASWELL) > > > > +#define m_HASWELL ((HOST_WIDE_INT_1U<<PROCESSOR_HASWELL) \ > > > > + | (HOST_WIDE_INT_1U<<PROCESSOR_SKYLAKE) \ > > > > + | (HOST_WIDE_INT_1U<<PROCESSOR_SKYLAKE_AVX512) \ > > > > + | (HOST_WIDE_INT_1U<<PROCESSOR_CANNONLAKE) \ > > > > + | (HOST_WIDE_INT_1U<<PROCESSOR_ICELAKE_CLIENT) \ > > > > + | (HOST_WIDE_INT_1U<<PROCESSOR_ICELAKE_SERVER)) > > > > > > > > > > Please introduce a new per-family define and group processors in this > > > define. Something like m_BDVER, m_BTVER and m_AMD_MULTIPLE for AMD > > targets. > > > We should not redefine m_HASWELL to include unrelated families. > > > > > > > Here is the updated patch. OK for trunk if all tests pass? > > > > > OK.
We have also noticed that benchmarks on skylake are not good compared to haswell, this nicely explains it. I think this is -march=native regression compared to GCC versions that did not suppored better CPUs than Haswell. So it would be nice to backport it. Honza
