> > > > 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

Reply via email to