This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86: Add -march=cascadelake


Hi Uros and other reviewers,

I'd like to split the work into 2 parts:
1) Basic processor enabling.
2) Processor type dynamic check.

Let's use a separate patch to implement the part 2.
The part 1 is implemented by attached patch.
Is it ok for trunk?

Wei

gcc/
      * common/config/i386/i386-common.c (processor_names): Add cascadelake.
      (processor_alias_table): Add cascadelake.
      * config.gcc: Add -march=cascadelake.
      * config/i386/i386-c.c (ix86_target_macros_internal): Handle cascadelake.
      * config/i386/i386.c (Add m_CASCADELAKE): New.
      (processor_cost_table): Add cascadelake.
      (get_builtin_code_for_version): Handle cascadelake.
      * config/i386/i386.h (TARGET_CASCADELAKE, PROCESSOR_CASCADELAKE): New.
      (PTA_CASCADELAKE): Ditto.
      * doc/invoke.texi: Add -march=cascadelake.

gcc/testsuite/
      * gcc.target/i386/funcspec-56.inc: Handle new march.
Wei Xiao <wei.william.xiao@gmail.com> 于2018年11月29日周四 下午4:32写道:
>
> Hi
>
> Distinguish based on stepping number is not recommended for some reasons:
> 1) Intel doesn't officially disclose stepping information in SDM.
> 2) Stepping can be changing in the future.
>
> We still prefer the conventional distinguish approach based on feature bits.
> I have refined the patch as attached according to all your suggestions.
>
> Wei
>
>     gcc/
>         * common/config/i386/i386-common.c (processor_names): Add cascadelake.
>         (processor_alias_table): Add cascadelake.
>         * config.gcc: Add -march=cascadelake.
>         * config/i386/driver-i386.c
>         (host_detect_local_cpu): Detect cascadelake.
>         * config/i386/i386-c.c (ix86_target_macros_internal): Handle
> cascadelake.
>         * config/i386/i386.c (ix86_cost): Add m_CASCADELAKE.
>         (processor_cost_table): Add cascadelake.
>         (get_builtin_code_for_version): Handle cascadelake.
>         (fold_builtin_cpu): Ditto.
>         * config/i386/i386.h (TARGET_CASCADELAKE, PROCESSOR_CASCADELAKE): New.
>         (PTA_CASCADELAKE): Ditto.
>         * doc/extend.texi: Add cascadelake.
>         * doc/invoke.texi: Add -march=cascadelake.
>     gcc/testsuite/
>         * g++.target/i386/mv16.C: Handle new march.
>         * gcc.target/i386/builtin_target.c: Ditto.
>         * gcc.target/i386/funcspec-56.inc: Ditto.
>     libgcc/
>         * config/i386/cpuinfo.c (get_intel_cpu): Handle cascadelake.
>         * config/i386/cpuinfo.h: Add INTEL_COREI7_CASCADELAKE.
> Wei Xiao <wei.william.xiao@gmail.com> 于2018年11月27日周二 下午6:40写道:
> >
> > Thanks for the helpful information!
> > But I'm still checking with hardware team about the
> > family/model/stepping numbers for Cascadelake which are not officially
> > disclosed by Intel (to my best knowledge).
> >
> > Wei
> > Martin Liška <mliska@suse.cz> 于2018年11月26日周一 下午10:00写道:
> > >
> > > On 11/26/18 12:18 PM, Jakub Jelinek wrote:
> > > > On Mon, Nov 26, 2018 at 12:03:53PM +0100, Martin Liška wrote:
> > > >>> For Cascade Lake the model number is the same as Skylake Server,
> > > >>> it can only be distinguished based on the stepping (5 vs 4)
> > > >>
> > > >> Very interesting, probably the first time a distinguish is based on stepping number?
> > > >
> > > > Wouldn't it be better to distinguish it based on availability of VNNI, like
> > > > we do for unknown family/model?
> > > >
> > > >>> Like gcc -mcpu=native needs to learn about this.
> > > >>
> > > >> I'm attaching patch that does that. Note that it's completely untested as I don't have
> > > >> access to any of the new machines (Skylake server).
> > >
> > > Would be possible, the only ugly place would be in libgcc/config/i386/cpuinfo.c where we
> > > call:
> > >
> > >       get_intel_cpu (family, model, stepping, brand_id);
> > >       /* Find available features. */
> > >       get_available_features (ecx, edx, max_level, &avx512_vnni);
> > >
> > > one would need a feature to distinguish CPU model. Do we really want that?
> > >
> > > Martin
> > >
> > > >
> > > >       Jakub
> > > >
> > >

Attachment: cascadelake-v4.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]