This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] x86: Add -march=cascadelake
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: wei dot william dot xiao at gmail dot com
- Cc: Martin Liska <mliska at suse dot cz>, Jakub Jelinek <jakub at redhat dot com>, Andi Kleen <ak at linux dot intel dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Lu, Hongjiu" <hongjiu dot lu at intel dot com>, Jeff Law <law at redhat dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, "H. J. Lu" <hjl dot tools at gmail dot com>, wei3 dot xiao at intel dot com
- Date: Wed, 12 Dec 2018 17:45:52 +0100
- Subject: Re: [PATCH] x86: Add -march=cascadelake
- References: <CAHFC=Nnb-Qi3pSxXoykS_1Bs2sVBYF_KK2ytfyKV7Ze1LAsPJA@mail.gmail.com> <20181121110916.GK11625@tucnak> <CAHFC=NnzsD2VRxOkPTcR=Op-5CLA4PdFjJoW57265YW1FcLmYA@mail.gmail.com> <58a237a2-d2d6-276d-07c6-31ab5564788d@suse.cz> <CAFULd4ayacr6HEYa=4AWfN=2e38oW86QLhPk+uMqtTw3i6YmDg@mail.gmail.com> <87o9afz7tv.fsf@linux.intel.com> <86f4e1a9-0ace-27d0-1dcf-e0611adae798@suse.cz> <20181126111828.GG12380@tucnak> <bc9e5e31-122f-2fab-5110-35c33e1a2bb5@suse.cz> <CAHFC=NnWqP03jeF2rrypVvwQj9K_1otWfVx-q+WJziQ3bOmJcA@mail.gmail.com> <CAHFC=NkVpSPm7mPHdRQD=ZnMJ2UZV-7n6xfLGYKZDnrxv=p_Sg@mail.gmail.com> <CAHFC=NnAKcCEMwfQL+a62xC7DEb4D=D+NAiCyA5aJRUMD9koKA@mail.gmail.com>
On Wed, Dec 12, 2018 at 10:48 AM Wei Xiao <wei.william.xiao@gmail.com> wrote:
>
> 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.
OK for mainline.
Thanks,
Uros.
> 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
> > > > >
> > > >