Re: [patch][x86] -march=icelake

2018-02-01 Thread Jakub Jelinek 
On Thu, Feb 01, 2018 at 08:49:09AM +0100, Uros Bizjak wrote:
> > gcc/c-family/
> > * c-common.h (omp_clause_mask): Move to wide_int_bitmask.h.
> >
> > gcc/
> > * config/i386/i386.c (ix86_option_override_internal): Change flags 
> > type to
> > wide_int_bitmask.
> > * wide-int-bitmask.h: New.
> >
> > Icelake patch changelog:
> >
> > gcc/
> > * config.gcc: Add -march=icelake.
> > * config/i386/driver-i386.c (host_detect_local_cpu): Detect icelake.
> > * config/i386/i386-c.c (ix86_target_macros_internal): Handle 
> > icelake.
> > * config/i386/i386.c (processor_costs): Add m_ICELAKE.
> > (PTA_ICELAKE, PTA_AVX512VNNI, PTA_GFNI, PTA_VAES, PTA_AVX512VBMI2,
> > PTA_VPCLMULQDQ, PTA_RDPID, PTA_AVX512BITALG): New.
> > (processor_target_table): Add icelake.
> > (ix86_option_override_internal): Handle new PTAs.
> > (get_builtin_code_for_version): Handle icelake.
> > (M_INTEL_COREI7_ICELAKE): New.
> > (fold_builtin_cpu): Handle icelake.
> > * config/i386/i386.h (TARGET_ICELAKE, PROCESSOR_ICELAKE): New.
> > * doc/invoke.texi: Add -march=icelake.
> > gcc/testsuite/
> > * gcc.target/i386/funcspec-56.inc: Handle new march.
> > * g++.dg/ext/mv16.C: Ditto.
> > libgcc/
> > * config/i386/cpuinfo.h (processor_subtypes): Add 
> > INTEL_COREI7_ICELAKE.
> 
> x86 parts are OK, generic parts need approval from global maintainer.

The generic parts are ok as well.

Jakub

Re: [patch][x86] -march=icelake

2018-01-31 Thread Uros Bizjak 
On Tue, Jan 30, 2018 at 12:53 PM, Koval, Julia <julia.ko...@intel.com> wrote:
> Thank you for your comments, fixed them and rebased Ice Lake patch on top of 
> it. Ok for trunk?
>
> Bitmask patch changelog:
>
> gcc/c-family/
> * c-common.h (omp_clause_mask): Move to wide_int_bitmask.h.
>
> gcc/
> * config/i386/i386.c (ix86_option_override_internal): Change flags 
> type to
> wide_int_bitmask.
> * wide-int-bitmask.h: New.
>
> Icelake patch changelog:
>
> gcc/
> * config.gcc: Add -march=icelake.
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect icelake.
> * config/i386/i386-c.c (ix86_target_macros_internal): Handle icelake.
> * config/i386/i386.c (processor_costs): Add m_ICELAKE.
> (PTA_ICELAKE, PTA_AVX512VNNI, PTA_GFNI, PTA_VAES, PTA_AVX512VBMI2,
> PTA_VPCLMULQDQ, PTA_RDPID, PTA_AVX512BITALG): New.
> (processor_target_table): Add icelake.
> (ix86_option_override_internal): Handle new PTAs.
> (get_builtin_code_for_version): Handle icelake.
> (M_INTEL_COREI7_ICELAKE): New.
> (fold_builtin_cpu): Handle icelake.
> * config/i386/i386.h (TARGET_ICELAKE, PROCESSOR_ICELAKE): New.
> * doc/invoke.texi: Add -march=icelake.
> gcc/testsuite/
> * gcc.target/i386/funcspec-56.inc: Handle new march.
> * g++.dg/ext/mv16.C: Ditto.
> libgcc/
> * config/i386/cpuinfo.h (processor_subtypes): Add 
> INTEL_COREI7_ICELAKE.

x86 parts are OK, generic parts need approval from global maintainer.

Thanks,
Uros.

> Thanks,
> Julia
>
>> -Original Message-
>> From: Jakub Jelinek [mailto:ja...@redhat.com]
>> Sent: Tuesday, January 30, 2018 9:47 AM
>> To: Koval, Julia <julia.ko...@intel.com>
>> Cc: Richard Biener <rguent...@suse.de>; Uros Bizjak <ubiz...@gmail.com>;
>> GCC Patches <gcc-patches@gcc.gnu.org>; Kirill Yukhin
>> <kirill.yuk...@gmail.com>
>> Subject: Re: [patch][x86] -march=icelake
>>
>> On Tue, Jan 30, 2018 at 08:35:38AM +, Koval, Julia wrote:
>> > * c-common.h (omp_clause_mask): Move to wide_int_bitmask.h
>>
>> Missing dot ad the end.
>>
>> +  wide_int_bitmask PTA_3DNOW (HOST_WIDE_INT_1U << 0);
>>
>> Can't all these be const wide_int_bitmask instead of just
>> wide_int_bitmask?
>>
>> ...
>> +
>> +  wide_int_bitmask PTA_CORE2 = PTA_64BIT | PTA_MMX | PTA_SSE |
>> PTA_SSE2
>> +| PTA_SSE3 | PTA_SSSE3 | PTA_CX16 | PTA_FXSR;
>> +  wide_int_bitmask PTA_NEHALEM = PTA_CORE2 | PTA_SSE4_1 | PTA_SSE4_2
>> +| PTA_POPCNT;
>> +  wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_AES |
>> PTA_PCLMUL;
>> +  wide_int_bitmask PTA_SANDYBRIDGE = PTA_WESTMERE | PTA_AVX |
>> PTA_XSAVE
>> +| PTA_XSAVEOPT;
>> +  wide_int_bitmask PTA_IVYBRIDGE = PTA_SANDYBRIDGE | PTA_FSGSBASE |
>> PTA_RDRND
>> +| PTA_F16C;
>> +  wide_int_bitmask PTA_HASWELL = PTA_IVYBRIDGE | PTA_AVX2 | PTA_BMI |
>> PTA_BMI2
>> +| PTA_LZCNT | PTA_FMA | PTA_MOVBE | PTA_HLE;
>> +  wide_int_bitmask PTA_BROADWELL = PTA_HASWELL | PTA_ADX |
>> PTA_PRFCHW
>> +| PTA_RDSEED;
>> +  wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_CLFLUSHOPT |
>> PTA_XSAVEC
>> +| PTA_XSAVES;
>> +  wide_int_bitmask PTA_SKYLAKE_AVX512 = PTA_SKYLAKE | PTA_AVX512F |
>> PTA_AVX512CD
>> +| PTA_AVX512VL | PTA_AVX512BW | PTA_AVX512DQ | PTA_PKU |
>> PTA_CLWB;
>> +  wide_int_bitmask PTA_CANNONLAKE = PTA_SKYLAKE_AVX512 |
>> PTA_AVX512VBMI
>> +| PTA_AVX512IFMA | PTA_SHA;
>> +  wide_int_bitmask PTA_KNL = PTA_BROADWELL | PTA_AVX512PF |
>> PTA_AVX512ER
>> +| PTA_AVX512F | PTA_AVX512CD;
>> +  wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
>> +  wide_int_bitmask PTA_SILVERMONT = PTA_WESTMERE | PTA_MOVBE |
>> PTA_RDRND;
>> +  wide_int_bitmask PTA_KNM = PTA_KNL | PTA_AVX5124VNNIW |
>> PTA_AVX5124FMAPS
>> +| PTA_AVX512VPOPCNTDQ;
>>
>> Likewise for these.
>>
>> --- /dev/null
>> +++ b/gcc/wide-int-bitmask.h
>> @@ -0,0 +1,145 @@
>> +/* Operation with 128 bit bitmask.
>> +   Copyright (C) 1987-2018 Free Software Foundation, Inc.
>>
>> Please use 2013-2018 instead, all the omp_clause_mask stuff was
>> introduced in 2013.
>>
>> +
>> +#ifndef GCC_BIT_MASK_H
>> +#define GCC_BIT_MASK_H
>>
>> The macro hasn't been renamed for the header file rename.
>>
>> +
>> +#endif /* ! GCC_BIT_MASK_H */
>>
>> Here as well.  Otherwise LGTM.
>>
>>   Jakub

RE: [patch][x86] -march=icelake

2018-01-30 Thread Koval, Julia 
Thank you for your comments, fixed them and rebased Ice Lake patch on top of 
it. Ok for trunk?

Bitmask patch changelog:

gcc/c-family/
* c-common.h (omp_clause_mask): Move to wide_int_bitmask.h.

gcc/
* config/i386/i386.c (ix86_option_override_internal): Change flags type 
to
wide_int_bitmask.
* wide-int-bitmask.h: New.

Icelake patch changelog:

gcc/
* config.gcc: Add -march=icelake.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect icelake.
* config/i386/i386-c.c (ix86_target_macros_internal): Handle icelake.
* config/i386/i386.c (processor_costs): Add m_ICELAKE.
(PTA_ICELAKE, PTA_AVX512VNNI, PTA_GFNI, PTA_VAES, PTA_AVX512VBMI2,
PTA_VPCLMULQDQ, PTA_RDPID, PTA_AVX512BITALG): New.
(processor_target_table): Add icelake.
(ix86_option_override_internal): Handle new PTAs.
(get_builtin_code_for_version): Handle icelake.
(M_INTEL_COREI7_ICELAKE): New.
(fold_builtin_cpu): Handle icelake.
* config/i386/i386.h (TARGET_ICELAKE, PROCESSOR_ICELAKE): New.
* doc/invoke.texi: Add -march=icelake.
gcc/testsuite/
* gcc.target/i386/funcspec-56.inc: Handle new march.
* g++.dg/ext/mv16.C: Ditto.
libgcc/
* config/i386/cpuinfo.h (processor_subtypes): Add INTEL_COREI7_ICELAKE.

Thanks,
Julia

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, January 30, 2018 9:47 AM
> To: Koval, Julia <julia.ko...@intel.com>
> Cc: Richard Biener <rguent...@suse.de>; Uros Bizjak <ubiz...@gmail.com>;
> GCC Patches <gcc-patches@gcc.gnu.org>; Kirill Yukhin
> <kirill.yuk...@gmail.com>
> Subject: Re: [patch][x86] -march=icelake
> 
> On Tue, Jan 30, 2018 at 08:35:38AM +, Koval, Julia wrote:
> > * c-common.h (omp_clause_mask): Move to wide_int_bitmask.h
> 
> Missing dot ad the end.
> 
> +  wide_int_bitmask PTA_3DNOW (HOST_WIDE_INT_1U << 0);
> 
> Can't all these be const wide_int_bitmask instead of just
> wide_int_bitmask?
> 
> ...
> +
> +  wide_int_bitmask PTA_CORE2 = PTA_64BIT | PTA_MMX | PTA_SSE |
> PTA_SSE2
> +| PTA_SSE3 | PTA_SSSE3 | PTA_CX16 | PTA_FXSR;
> +  wide_int_bitmask PTA_NEHALEM = PTA_CORE2 | PTA_SSE4_1 | PTA_SSE4_2
> +| PTA_POPCNT;
> +  wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_AES |
> PTA_PCLMUL;
> +  wide_int_bitmask PTA_SANDYBRIDGE = PTA_WESTMERE | PTA_AVX |
> PTA_XSAVE
> +| PTA_XSAVEOPT;
> +  wide_int_bitmask PTA_IVYBRIDGE = PTA_SANDYBRIDGE | PTA_FSGSBASE |
> PTA_RDRND
> +| PTA_F16C;
> +  wide_int_bitmask PTA_HASWELL = PTA_IVYBRIDGE | PTA_AVX2 | PTA_BMI |
> PTA_BMI2
> +| PTA_LZCNT | PTA_FMA | PTA_MOVBE | PTA_HLE;
> +  wide_int_bitmask PTA_BROADWELL = PTA_HASWELL | PTA_ADX |
> PTA_PRFCHW
> +| PTA_RDSEED;
> +  wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_CLFLUSHOPT |
> PTA_XSAVEC
> +| PTA_XSAVES;
> +  wide_int_bitmask PTA_SKYLAKE_AVX512 = PTA_SKYLAKE | PTA_AVX512F |
> PTA_AVX512CD
> +| PTA_AVX512VL | PTA_AVX512BW | PTA_AVX512DQ | PTA_PKU |
> PTA_CLWB;
> +  wide_int_bitmask PTA_CANNONLAKE = PTA_SKYLAKE_AVX512 |
> PTA_AVX512VBMI
> +| PTA_AVX512IFMA | PTA_SHA;
> +  wide_int_bitmask PTA_KNL = PTA_BROADWELL | PTA_AVX512PF |
> PTA_AVX512ER
> +| PTA_AVX512F | PTA_AVX512CD;
> +  wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
> +  wide_int_bitmask PTA_SILVERMONT = PTA_WESTMERE | PTA_MOVBE |
> PTA_RDRND;
> +  wide_int_bitmask PTA_KNM = PTA_KNL | PTA_AVX5124VNNIW |
> PTA_AVX5124FMAPS
> +| PTA_AVX512VPOPCNTDQ;
> 
> Likewise for these.
> 
> --- /dev/null
> +++ b/gcc/wide-int-bitmask.h
> @@ -0,0 +1,145 @@
> +/* Operation with 128 bit bitmask.
> +   Copyright (C) 1987-2018 Free Software Foundation, Inc.
> 
> Please use 2013-2018 instead, all the omp_clause_mask stuff was
> introduced in 2013.
> 
> +
> +#ifndef GCC_BIT_MASK_H
> +#define GCC_BIT_MASK_H
> 
> The macro hasn't been renamed for the header file rename.
> 
> +
> +#endif /* ! GCC_BIT_MASK_H */
> 
> Here as well.  Otherwise LGTM.
> 
>   Jakub


0001-bitmask.patch
Description: 0001-bitmask.patch


0002-icelake_rebased.patch
Description: 0002-icelake_rebased.patch

Re: [patch][x86] -march=icelake

2018-01-30 Thread Jakub Jelinek 
On Tue, Jan 30, 2018 at 08:35:38AM +, Koval, Julia wrote:
>   * c-common.h (omp_clause_mask): Move to wide_int_bitmask.h

Missing dot ad the end.

+  wide_int_bitmask PTA_3DNOW (HOST_WIDE_INT_1U << 0);

Can't all these be const wide_int_bitmask instead of just
wide_int_bitmask?

...
+
+  wide_int_bitmask PTA_CORE2 = PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2
+| PTA_SSE3 | PTA_SSSE3 | PTA_CX16 | PTA_FXSR;
+  wide_int_bitmask PTA_NEHALEM = PTA_CORE2 | PTA_SSE4_1 | PTA_SSE4_2
+| PTA_POPCNT;
+  wide_int_bitmask PTA_WESTMERE = PTA_NEHALEM | PTA_AES | PTA_PCLMUL;
+  wide_int_bitmask PTA_SANDYBRIDGE = PTA_WESTMERE | PTA_AVX | PTA_XSAVE
+| PTA_XSAVEOPT;
+  wide_int_bitmask PTA_IVYBRIDGE = PTA_SANDYBRIDGE | PTA_FSGSBASE | PTA_RDRND
+| PTA_F16C;
+  wide_int_bitmask PTA_HASWELL = PTA_IVYBRIDGE | PTA_AVX2 | PTA_BMI | PTA_BMI2
+| PTA_LZCNT | PTA_FMA | PTA_MOVBE | PTA_HLE;
+  wide_int_bitmask PTA_BROADWELL = PTA_HASWELL | PTA_ADX | PTA_PRFCHW
+| PTA_RDSEED;
+  wide_int_bitmask PTA_SKYLAKE = PTA_BROADWELL | PTA_CLFLUSHOPT | PTA_XSAVEC
+| PTA_XSAVES;
+  wide_int_bitmask PTA_SKYLAKE_AVX512 = PTA_SKYLAKE | PTA_AVX512F | 
PTA_AVX512CD
+| PTA_AVX512VL | PTA_AVX512BW | PTA_AVX512DQ | PTA_PKU | PTA_CLWB;
+  wide_int_bitmask PTA_CANNONLAKE = PTA_SKYLAKE_AVX512 | PTA_AVX512VBMI
+| PTA_AVX512IFMA | PTA_SHA;
+  wide_int_bitmask PTA_KNL = PTA_BROADWELL | PTA_AVX512PF | PTA_AVX512ER
+| PTA_AVX512F | PTA_AVX512CD;
+  wide_int_bitmask PTA_BONNELL = PTA_CORE2 | PTA_MOVBE;
+  wide_int_bitmask PTA_SILVERMONT = PTA_WESTMERE | PTA_MOVBE | PTA_RDRND;
+  wide_int_bitmask PTA_KNM = PTA_KNL | PTA_AVX5124VNNIW | PTA_AVX5124FMAPS
+| PTA_AVX512VPOPCNTDQ;

Likewise for these.

--- /dev/null
+++ b/gcc/wide-int-bitmask.h
@@ -0,0 +1,145 @@
+/* Operation with 128 bit bitmask.
+   Copyright (C) 1987-2018 Free Software Foundation, Inc.

Please use 2013-2018 instead, all the omp_clause_mask stuff was
introduced in 2013.

+
+#ifndef GCC_BIT_MASK_H
+#define GCC_BIT_MASK_H

The macro hasn't been renamed for the header file rename.

+
+#endif /* ! GCC_BIT_MASK_H */

Here as well.  Otherwise LGTM.

Jakub

RE: [patch][x86] -march=icelake

2018-01-30 Thread Koval, Julia 
Renamed it. Ok for trunk?

gcc/c-family/
* c-common.h (omp_clause_mask): Move to wide_int_bitmask.h

gcc/
* config/i386/i386.c (ix86_option_override_internal): Change flags type 
to
wide_int_bitmask.
* wide-int-bitmask.h: New.

Thanks,
Julia


> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: Wednesday, January 24, 2018 12:18 PM
> To: Koval, Julia <julia.ko...@intel.com>
> Cc: Jakub Jelinek <ja...@redhat.com>; Uros Bizjak <ubiz...@gmail.com>; GCC
> Patches <gcc-patches@gcc.gnu.org>; Kirill Yukhin <kirill.yuk...@gmail.com>
> Subject: RE: [patch][x86] -march=icelake
> 
> On Wed, 24 Jan 2018, Koval, Julia wrote:
> 
> > I think we may want to extend it to more than 2 ints someday, when we run
> out of bits again. It won't break the existing functionality if 3rd int will 
> be zero by
> default. That's why I tried to avoid "two" in the name.
> >
> > Julia
> >
> > > -Original Message-
> > > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > > Sent: Wednesday, January 24, 2018 12:06 PM
> > > To: Uros Bizjak <ubiz...@gmail.com>; Richard Biener <rguent...@suse.de>
> > > Cc: Koval, Julia <julia.ko...@intel.com>; GCC Patches  > > patc...@gcc.gnu.org>; Kirill Yukhin <kirill.yuk...@gmail.com>
> > > Subject: Re: [patch][x86] -march=icelake
> > >
> > > On Wed, Jan 24, 2018 at 12:00:26PM +0100, Uros Bizjak wrote:
> > > > On Mon, Jan 22, 2018 at 3:44 PM, Koval, Julia <julia.ko...@intel.com>
> wrote:
> > > > > Yes, you are right, any() is not required. Here is the patch.
> > > >
> > > > Please also attach ChangeLog.
> > > >
> > > > The patch is OK for x86 target, it needs global reviewer approval
> > > > (Maybe Jakub, as the patch touches OMP part).
> > >
> > > I don't like the new class name nor header name, bit_mask is way too
> generic
> > > name for something very specialized (double hwi bitmask).
> > >
> > > Richard, any suggestions for this?
> 
> Maybe wide_int_bitmask?  You could then even use fixed_wide_int <> as
> "implementation".
> 
> Richard.


0001-bitmask.patch
Description: 0001-bitmask.patch

RE: [patch][x86] -march=icelake

2018-01-24 Thread Richard Biener 
On Wed, 24 Jan 2018, Koval, Julia wrote:

> I think we may want to extend it to more than 2 ints someday, when we run out 
> of bits again. It won't break the existing functionality if 3rd int will be 
> zero by default. That's why I tried to avoid "two" in the name.
> 
> Julia
> 
> > -Original Message-
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > Sent: Wednesday, January 24, 2018 12:06 PM
> > To: Uros Bizjak <ubiz...@gmail.com>; Richard Biener <rguent...@suse.de>
> > Cc: Koval, Julia <julia.ko...@intel.com>; GCC Patches  > patc...@gcc.gnu.org>; Kirill Yukhin <kirill.yuk...@gmail.com>
> > Subject: Re: [patch][x86] -march=icelake
> > 
> > On Wed, Jan 24, 2018 at 12:00:26PM +0100, Uros Bizjak wrote:
> > > On Mon, Jan 22, 2018 at 3:44 PM, Koval, Julia <julia.ko...@intel.com> 
> > > wrote:
> > > > Yes, you are right, any() is not required. Here is the patch.
> > >
> > > Please also attach ChangeLog.
> > >
> > > The patch is OK for x86 target, it needs global reviewer approval
> > > (Maybe Jakub, as the patch touches OMP part).
> > 
> > I don't like the new class name nor header name, bit_mask is way too generic
> > name for something very specialized (double hwi bitmask).
> > 
> > Richard, any suggestions for this?

Maybe wide_int_bitmask?  You could then even use fixed_wide_int <> as
"implementation".

Richard.

RE: [patch][x86] -march=icelake

2018-01-24 Thread Koval, Julia 
I think we may want to extend it to more than 2 ints someday, when we run out 
of bits again. It won't break the existing functionality if 3rd int will be 
zero by default. That's why I tried to avoid "two" in the name.

Julia

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, January 24, 2018 12:06 PM
> To: Uros Bizjak <ubiz...@gmail.com>; Richard Biener <rguent...@suse.de>
> Cc: Koval, Julia <julia.ko...@intel.com>; GCC Patches  patc...@gcc.gnu.org>; Kirill Yukhin <kirill.yuk...@gmail.com>
> Subject: Re: [patch][x86] -march=icelake
> 
> On Wed, Jan 24, 2018 at 12:00:26PM +0100, Uros Bizjak wrote:
> > On Mon, Jan 22, 2018 at 3:44 PM, Koval, Julia <julia.ko...@intel.com> wrote:
> > > Yes, you are right, any() is not required. Here is the patch.
> >
> > Please also attach ChangeLog.
> >
> > The patch is OK for x86 target, it needs global reviewer approval
> > (Maybe Jakub, as the patch touches OMP part).
> 
> I don't like the new class name nor header name, bit_mask is way too generic
> name for something very specialized (double hwi bitmask).
> 
> Richard, any suggestions for this?
> 
>   Jakub

Re: [patch][x86] -march=icelake

2018-01-24 Thread Jakub Jelinek 
On Wed, Jan 24, 2018 at 12:00:26PM +0100, Uros Bizjak wrote:
> On Mon, Jan 22, 2018 at 3:44 PM, Koval, Julia  wrote:
> > Yes, you are right, any() is not required. Here is the patch.
> 
> Please also attach ChangeLog.
> 
> The patch is OK for x86 target, it needs global reviewer approval
> (Maybe Jakub, as the patch touches OMP part).

I don't like the new class name nor header name, bit_mask is way too generic
name for something very specialized (double hwi bitmask).

Richard, any suggestions for this?

Jakub

Re: [patch][x86] -march=icelake

2018-01-24 Thread Uros Bizjak 
On Mon, Jan 22, 2018 at 3:44 PM, Koval, Julia <julia.ko...@intel.com> wrote:
> Yes, you are right, any() is not required. Here is the patch.

Please also attach ChangeLog.

The patch is OK for x86 target, it needs global reviewer approval
(Maybe Jakub, as the patch touches OMP part).

Uros.

> Thanks,
> Julia
>
>> -Original Message-
>> From: Jakub Jelinek [mailto:ja...@redhat.com]
>> Sent: Monday, January 22, 2018 12:36 PM
>> To: Koval, Julia <julia.ko...@intel.com>
>> Cc: Richard Biener <richard.guent...@gmail.com>; Uros Bizjak
>> <ubiz...@gmail.com>; GCC Patches <gcc-patches@gcc.gnu.org>; Kirill Yukhin
>> <kirill.yuk...@gmail.com>
>> Subject: Re: [patch][x86] -march=icelake
>>
>> On Mon, Jan 22, 2018 at 11:30:10AM +, Koval, Julia wrote:
>> > Hi, I tried omp_clause_mask and it looks ok.  But it lacks check if there
>> > is any bit or none.  With addition of it(as proposed or in some other way
>> > it should work.  What do you think about this approach(patch attached)?
>>
>> Well, I certainly didn't mean to use omp_clause_mask for something
>> completely unrelated to OpenMP, the reason I've mentioned it is that it is a
>> class that deals with a similar problem.
>>
>> So, if you want to use the same class, it would need to be moved to some
>> generic header, renamed and then c-common.h would typedef that_class
>> omp_clause_mask.
>>
>> I'm surprised you need any, doesn't ((mask & (...)) != 0 already handle
>> that?
>>
>>   Jakub
>

RE: [patch][x86] -march=icelake

2018-01-22 Thread Koval, Julia 
Yes, you are right, any() is not required. Here is the patch.

Thanks,
Julia

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Monday, January 22, 2018 12:36 PM
> To: Koval, Julia <julia.ko...@intel.com>
> Cc: Richard Biener <richard.guent...@gmail.com>; Uros Bizjak
> <ubiz...@gmail.com>; GCC Patches <gcc-patches@gcc.gnu.org>; Kirill Yukhin
> <kirill.yuk...@gmail.com>
> Subject: Re: [patch][x86] -march=icelake
> 
> On Mon, Jan 22, 2018 at 11:30:10AM +, Koval, Julia wrote:
> > Hi, I tried omp_clause_mask and it looks ok.  But it lacks check if there
> > is any bit or none.  With addition of it(as proposed or in some other way
> > it should work.  What do you think about this approach(patch attached)?
> 
> Well, I certainly didn't mean to use omp_clause_mask for something
> completely unrelated to OpenMP, the reason I've mentioned it is that it is a
> class that deals with a similar problem.
> 
> So, if you want to use the same class, it would need to be moved to some
> generic header, renamed and then c-common.h would typedef that_class
> omp_clause_mask.
> 
> I'm surprised you need any, doesn't ((mask & (...)) != 0 already handle
> that?
> 
>   Jakub



0001-test.patch
Description: 0001-test.patch

Re: [patch][x86] -march=icelake

2018-01-22 Thread Jakub Jelinek 
On Mon, Jan 22, 2018 at 11:30:10AM +, Koval, Julia wrote:
> Hi, I tried omp_clause_mask and it looks ok.  But it lacks check if there
> is any bit or none.  With addition of it(as proposed or in some other way
> it should work.  What do you think about this approach(patch attached)?

Well, I certainly didn't mean to use omp_clause_mask for something
completely unrelated to OpenMP, the reason I've mentioned it is that it is a
class that deals with a similar problem.

So, if you want to use the same class, it would need to be moved to some
generic header, renamed and then c-common.h would typedef that_class
omp_clause_mask.

I'm surprised you need any, doesn't ((mask & (...)) != 0 already handle
that?

Jakub

RE: [patch][x86] -march=icelake

2018-01-22 Thread Koval, Julia 
Hi,
I tried omp_clause_mask and it looks ok. But it lacks check if there is any bit 
or none. With addition of it(as proposed or in some other way it should work. 
What do you think about this approach(patch attached)?

Thanks,
Julia

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, December 19, 2017 2:50 PM
> To: Koval, Julia <julia.ko...@intel.com>
> Cc: Richard Biener <richard.guent...@gmail.com>; Uros Bizjak
> <ubiz...@gmail.com>; GCC Patches <gcc-patches@gcc.gnu.org>; Kirill Yukhin
> <kirill.yuk...@gmail.com>
> Subject: Re: [patch][x86] -march=icelake
> 
> On Tue, Dec 19, 2017 at 12:34:03PM +, Koval, Julia wrote:
> > >> Maybe [] operator could be used instead of a dynamic handling here.
> > I had another solution in mind, with enums, which then addresses elements
> using its index, please look the patch attached.
> 
> You can also have a look at the omp_clause_mask class in c-common.h, that is
> also something that has been added to handle the case where we run out of
> 64-bits for a particular bitmask, wanted to keep using pretty much the same
> interfaces and be able to handle it fast.  Using 2 enums for the two halves
> and treating it accordingly is also an option.
> 
> I agree sbitmap is too heavy for this.
> 
>   Jakub


0001-test.patch
Description: 0001-test.patch

Re: [patch][x86] -march=icelake

2017-12-19 Thread Jakub Jelinek 
On Tue, Dec 19, 2017 at 12:34:03PM +, Koval, Julia wrote:
> >> Maybe [] operator could be used instead of a dynamic handling here.
> I had another solution in mind, with enums, which then addresses elements 
> using its index, please look the patch attached.

You can also have a look at the omp_clause_mask class in c-common.h, that is
also something that has been added to handle the case where we run out of
64-bits for a particular bitmask, wanted to keep using pretty much the same
interfaces and be able to handle it fast.  Using 2 enums for the two halves
and treating it accordingly is also an option.

I agree sbitmap is too heavy for this.

Jakub

Re: [patch][x86] -march=icelake

2017-12-19 Thread Richard Biener 
On Tue, Dec 19, 2017 at 1:34 PM, Koval, Julia <julia.ko...@intel.com> wrote:
>>> Maybe [] operator could be used instead of a dynamic handling here.
> I had another solution in mind, with enums, which then addresses elements 
> using its index, please look the patch attached.
>
>
>>>> The natural GCC data structure is a sbitmap ...  I'd rather not use 
>>>>  given we have a GCC variant.
>
> Sorry for maybe stupid question, but how do we set
>
>   bitmask pta_core2  = pta_64bit | pta_mmx | pta_sse | pta_sse2
>| pta_sse3 | pta_ssse3 | pta_cx16 | pta_fxsr;
>
> in sbitmap, except chain of bitmap_and_or with third bitmap set to ones(which 
> doesn't look fast)?
> Sorry, I think there should be some obvious solution, but can't find a proper 
> function.

Chain of bitmap_set_bit () I'd say.  Or are the pta_64bit and friends
bitsets themselves?

Richard.

> Thanks,
> Julia
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, December 19, 2017 12:56 PM
>> To: Uros Bizjak <ubiz...@gmail.com>
>> Cc: Koval, Julia <julia.ko...@intel.com>; GCC Patches > patc...@gcc.gnu.org>; Kirill Yukhin <kirill.yuk...@gmail.com>
>> Subject: Re: [patch][x86] -march=icelake
>>
>> On Tue, Dec 19, 2017 at 9:29 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>> > On Mon, Dec 18, 2017 at 2:42 PM, Koval, Julia <julia.ko...@intel.com> 
>> > wrote:
>> >> Hi, I tried to replace 2 flags variable with c++ bitset(in patch 
>> >> attached). What
>> do you think?
>> >
>> > Hm, I'm not a c++ person, but I wonder about overhead and performance
>> > impact of this change. Maybe [] operator could be used instead of a
>> > dynamic handling here. Please discuss with a c++ person to find out
>> > the most appropriate approach.
>>
>> The natural GCC data structure is a sbitmap ...  I'd rather not use 
>> given we have a GCC variant.
>>
>> >>> Please add these options first.
>> >> 2 options left(they are under Kirill's review currently), I'll add PTAs 
>> >> for them to
>> the patch, as soon as they will be commited.
>> >
>> > Actually, let's wait for these 2 options to be reviewed and committed
>> > first, and after that introduce -march=icelake handling.
>> >
>> > Uros.

RE: [patch][x86] -march=icelake

2017-12-19 Thread Koval, Julia 
>> Maybe [] operator could be used instead of a dynamic handling here.
I had another solution in mind, with enums, which then addresses elements using 
its index, please look the patch attached.


>>> The natural GCC data structure is a sbitmap ...  I'd rather not use 
>>>  given we have a GCC variant.

Sorry for maybe stupid question, but how do we set 

  bitmask pta_core2  = pta_64bit | pta_mmx | pta_sse | pta_sse2
   | pta_sse3 | pta_ssse3 | pta_cx16 | pta_fxsr;

in sbitmap, except chain of bitmap_and_or with third bitmap set to ones(which 
doesn't look fast)?
Sorry, I think there should be some obvious solution, but can't find a proper 
function.

Thanks,
Julia

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, December 19, 2017 12:56 PM
> To: Uros Bizjak <ubiz...@gmail.com>
> Cc: Koval, Julia <julia.ko...@intel.com>; GCC Patches  patc...@gcc.gnu.org>; Kirill Yukhin <kirill.yuk...@gmail.com>
> Subject: Re: [patch][x86] -march=icelake
> 
> On Tue, Dec 19, 2017 at 9:29 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> > On Mon, Dec 18, 2017 at 2:42 PM, Koval, Julia <julia.ko...@intel.com> wrote:
> >> Hi, I tried to replace 2 flags variable with c++ bitset(in patch 
> >> attached). What
> do you think?
> >
> > Hm, I'm not a c++ person, but I wonder about overhead and performance
> > impact of this change. Maybe [] operator could be used instead of a
> > dynamic handling here. Please discuss with a c++ person to find out
> > the most appropriate approach.
> 
> The natural GCC data structure is a sbitmap ...  I'd rather not use 
> given we have a GCC variant.
> 
> >>> Please add these options first.
> >> 2 options left(they are under Kirill's review currently), I'll add PTAs 
> >> for them to
> the patch, as soon as they will be commited.
> >
> > Actually, let's wait for these 2 options to be reviewed and committed
> > first, and after that introduce -march=icelake handling.
> >
> > Uros.


0001-icelake.patch_enums
Description: 0001-icelake.patch_enums

Re: [patch][x86] -march=icelake

2017-12-19 Thread Richard Biener 
On Tue, Dec 19, 2017 at 9:29 AM, Uros Bizjak  wrote:
> On Mon, Dec 18, 2017 at 2:42 PM, Koval, Julia  wrote:
>> Hi, I tried to replace 2 flags variable with c++ bitset(in patch attached). 
>> What do you think?
>
> Hm, I'm not a c++ person, but I wonder about overhead and performance
> impact of this change. Maybe [] operator could be used instead of a
> dynamic handling here. Please discuss with a c++ person to find out
> the most appropriate approach.

The natural GCC data structure is a sbitmap ...  I'd rather not use 
given we have a GCC variant.

>>> Please add these options first.
>> 2 options left(they are under Kirill's review currently), I'll add PTAs for 
>> them to the patch, as soon as they will be commited.
>
> Actually, let's wait for these 2 options to be reviewed and committed
> first, and after that introduce -march=icelake handling.
>
> Uros.

Re: [patch][x86] -march=icelake

2017-12-19 Thread Uros Bizjak 
On Mon, Dec 18, 2017 at 2:42 PM, Koval, Julia  wrote:
> Hi, I tried to replace 2 flags variable with c++ bitset(in patch attached). 
> What do you think?

Hm, I'm not a c++ person, but I wonder about overhead and performance
impact of this change. Maybe [] operator could be used instead of a
dynamic handling here. Please discuss with a c++ person to find out
the most appropriate approach.

>> Please add these options first.
> 2 options left(they are under Kirill's review currently), I'll add PTAs for 
> them to the patch, as soon as they will be commited.

Actually, let's wait for these 2 options to be reviewed and committed
first, and after that introduce -march=icelake handling.

Uros.

RE: [patch][x86] -march=icelake

2017-12-18 Thread Koval, Julia 
Hi, I tried to replace 2 flags variable with c++ bitset(in patch attached). 
What do you think?

> Please add these options first.
2 options left(they are under Kirill's review currently), I'll add PTAs for 
them to the patch, as soon as they will be commited.

Thanks,
Julia


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Uros Bizjak
> Sent: Sunday, November 12, 2017 5:30 PM
> To: Koval, Julia <julia.ko...@intel.com>
> Cc: GCC Patches <gcc-patches@gcc.gnu.org>; Kirill Yukhin
> <kirill.yuk...@gmail.com>
> Subject: Re: [patch][x86] -march=icelake
> 
> On Sun, Nov 12, 2017 at 1:04 AM, Koval, Julia <julia.ko...@intel.com> wrote:
> > Hi, this patch adds new option -march=icelake. Isasets defined in:
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-
> instruction-set-extensions-programming-reference.pdf
> > I didn't add arch code to driver-i386.c, because there is no code available 
> > in
> SDM yet, only for cannonlake
> (https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-
> vol-1-2abcd-3abcd.pdf Chapter 2).
> 
> This means the driver will go through generic detection for
> -march=native. Perhaps a comment should be added, so we won't forget
> to add the model number when one is available.
> 
> > gcc/
> > * config.gcc: Add -march=icelake.
> > * config/i386/driver-i386.c (host_detect_local_cpu): Detect icelake.
> > * config/i386/i386-c.c (ix86_target_macros_internal): Handle 
> > icelake.
> > * config/i386/i386.c (processor_costs): Add m_ICELAKE.
> > (PTA_ICELAKE, PTA2_ICELAKE, PTA2_GFNI, PTA2_AVX512VBMI2,
> PTA2_VAES,
> > PTA2_AVX512VNNI, PTA2_VPCLMULQDQ, PTA2_RDPID,
> PTA2_AVX512BITALG): New.
> > (processor_target_table): Add icelake.
> > (ix86_option_override_internal): Add flags2 for new PTA, handle 
> > GFNI,
> RDPID.
> > (get_builtin_code_for_version): Handle icelake.
> > (M_INTEL_COREI7_ICELAKE): New.
> > * config/i386/i386.h (TARGET_ICELAKE, PROCESSOR_ICELAKE): New.
> > * doc/invoke.texi: Add -march=icelake.
> > gcc/testsuite/
> > * gcc.target/i386/funcspec-56.inc: Handle new march.
> > * g++.dg/ext/mv16.C: Ditto.
> > libgcc/
> > * config/i386/cpuinfo.h (processor_subtypes): Add
> INTEL_COREI7_ICELAKE.
> 
> @@ -3425,6 +3427,13 @@ ix86_option_override_internal (bool main_args_p,
>  #define PTA_AVX5124FMAPS(HOST_WIDE_INT_1 << 61)
>  #define PTA_AVX512VPOPCNTDQ(HOST_WIDE_INT_1 << 62)
>  #define PTA_SGX(HOST_WIDE_INT_1 << 63)
> +#define PTA2_GFNI(HOST_WIDE_INT_1 << 0)
> +#define PTA2_AVX512VBMI2(HOST_WIDE_INT_1 << 1)
> +#define PTA2_VAES(HOST_WIDE_INT_1 << 2)
> +#define PTA2_AVX512VNNI(HOST_WIDE_INT_1 << 3)
> +#define PTA2_VPCLMULQDQ(HOST_WIDE_INT_1 << 4)
> +#define PTA2_RDPID(HOST_WIDE_INT_1 << 5)
> +#define PTA2_AVX512BITALG(HOST_WIDE_INT_1 << 6)
> 
> Please add these options first.
> 
> On a related note, there should probably be a better way to extend
> various bitmapped flag variables beyond 64bit words. We are constantly
> going over 64bit sizes in target option masks, now the number of
> processor flags doesn't fit in a word anymore. There are several
> places one has to keep in mind in which word some specific flag lives,
> and this  approach opens several ways to make a hard to detect
> mistake. Does C++ offer a more elegant way?
> 
> Bellow, please find a suggestion of a couple of cosmetic changes.
> 
> Thanks,
> Uros.
> 
> @@ -3425,6 +3427,13 @@ ix86_option_override_internal (bool main_args_p,
>  #define PTA_AVX5124FMAPS(HOST_WIDE_INT_1 << 61)
>  #define PTA_AVX512VPOPCNTDQ(HOST_WIDE_INT_1 << 62)
>  #define PTA_SGX(HOST_WIDE_INT_1 << 63)
> 
> Please add a comment here, that the folowing belongs to flags2.
> 
> +#define PTA2_GFNI(HOST_WIDE_INT_1 << 0)
> +#define PTA2_AVX512VBMI2(HOST_WIDE_INT_1 << 1)
> +#define PTA2_VAES(HOST_WIDE_INT_1 << 2)
> 
> 
> @@ -4105,6 +4124,12 @@ ix86_option_override_internal (bool main_args_p,
>  if (processor_alias_table[i].flags & PTA_SGX
>  && !(opts->x_ix86_isa_flags2_explicit & OPTION_MASK_ISA_SGX))
>opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA_SGX;
> 
> Please add vertical space here to visually separate flags and flags2 
> processing.
> 
> +if (processor_alias_table[i].flags2 & PTA2_RDPID
> +&& !(opts->x_ix86_isa_flags2_explicit & OPTION_MASK_ISA_RDPID))
> +  opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA_RDPID;


0001-icelake.patch
Description: 0001-icelake.patch

Re: [patch][x86] -march=icelake

2017-11-12 Thread Sandra Loosemore 

On 11/11/2017 05:04 PM, Koval, Julia wrote:

Hi, this patch adds new option -march=icelake.
[snip]

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index bc6e86f..891c283 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -25331,6 +25331,14 @@ RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, 
CLFLUSHOPT, XSAVEC,
 XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, AVX512VBMI,
 AVX512IFMA, SHA, CLWB and UMIP instruction set support.
 
+@item Icelake

+Intel Icelake Server CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2,
+SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, PKU, AVX, AVX2, AES, PCLMUL, FSGSBASE,
+RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX, PREFETCHW, CLFLUSHOPT, XSAVEC,
+XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, AVX512VBMI,
+AVX512IFMA, SHA, CLWB, UMIP, RDPID, GFNI, AVX512VBMI2, AVX512VPOPCNTDQ,
+AVX512BITALG, AVX512VNNI, VPCLMULQDQ, VAES instruction set support.
+
 @item k6
 AMD K6 CPU with MMX instruction set support.


Since it's -march=icelake (all lower case),

s/@item Icelake/@item icelake/

-Sandra

Re: [patch][x86] -march=icelake

2017-11-12 Thread Uros Bizjak 
On Sun, Nov 12, 2017 at 1:04 AM, Koval, Julia  wrote:
> Hi, this patch adds new option -march=icelake. Isasets defined in: 
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> I didn't add arch code to driver-i386.c, because there is no code available 
> in SDM yet, only for cannonlake 
> (https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
>  Chapter 2).

This means the driver will go through generic detection for
-march=native. Perhaps a comment should be added, so we won't forget
to add the model number when one is available.

> gcc/
> * config.gcc: Add -march=icelake.
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect icelake.
> * config/i386/i386-c.c (ix86_target_macros_internal): Handle icelake.
> * config/i386/i386.c (processor_costs): Add m_ICELAKE.
> (PTA_ICELAKE, PTA2_ICELAKE, PTA2_GFNI, PTA2_AVX512VBMI2, PTA2_VAES,
> PTA2_AVX512VNNI, PTA2_VPCLMULQDQ, PTA2_RDPID, PTA2_AVX512BITALG): New.
> (processor_target_table): Add icelake.
> (ix86_option_override_internal): Add flags2 for new PTA, handle GFNI, 
> RDPID.
> (get_builtin_code_for_version): Handle icelake.
> (M_INTEL_COREI7_ICELAKE): New.
> * config/i386/i386.h (TARGET_ICELAKE, PROCESSOR_ICELAKE): New.
> * doc/invoke.texi: Add -march=icelake.
> gcc/testsuite/
> * gcc.target/i386/funcspec-56.inc: Handle new march.
> * g++.dg/ext/mv16.C: Ditto.
> libgcc/
> * config/i386/cpuinfo.h (processor_subtypes): Add 
> INTEL_COREI7_ICELAKE.

@@ -3425,6 +3427,13 @@ ix86_option_override_internal (bool main_args_p,
 #define PTA_AVX5124FMAPS(HOST_WIDE_INT_1 << 61)
 #define PTA_AVX512VPOPCNTDQ(HOST_WIDE_INT_1 << 62)
 #define PTA_SGX(HOST_WIDE_INT_1 << 63)
+#define PTA2_GFNI(HOST_WIDE_INT_1 << 0)
+#define PTA2_AVX512VBMI2(HOST_WIDE_INT_1 << 1)
+#define PTA2_VAES(HOST_WIDE_INT_1 << 2)
+#define PTA2_AVX512VNNI(HOST_WIDE_INT_1 << 3)
+#define PTA2_VPCLMULQDQ(HOST_WIDE_INT_1 << 4)
+#define PTA2_RDPID(HOST_WIDE_INT_1 << 5)
+#define PTA2_AVX512BITALG(HOST_WIDE_INT_1 << 6)

Please add these options first.

On a related note, there should probably be a better way to extend
various bitmapped flag variables beyond 64bit words. We are constantly
going over 64bit sizes in target option masks, now the number of
processor flags doesn't fit in a word anymore. There are several
places one has to keep in mind in which word some specific flag lives,
and this  approach opens several ways to make a hard to detect
mistake. Does C++ offer a more elegant way?

Bellow, please find a suggestion of a couple of cosmetic changes.

Thanks,
Uros.

@@ -3425,6 +3427,13 @@ ix86_option_override_internal (bool main_args_p,
 #define PTA_AVX5124FMAPS(HOST_WIDE_INT_1 << 61)
 #define PTA_AVX512VPOPCNTDQ(HOST_WIDE_INT_1 << 62)
 #define PTA_SGX(HOST_WIDE_INT_1 << 63)

Please add a comment here, that the folowing belongs to flags2.

+#define PTA2_GFNI(HOST_WIDE_INT_1 << 0)
+#define PTA2_AVX512VBMI2(HOST_WIDE_INT_1 << 1)
+#define PTA2_VAES(HOST_WIDE_INT_1 << 2)


@@ -4105,6 +4124,12 @@ ix86_option_override_internal (bool main_args_p,
 if (processor_alias_table[i].flags & PTA_SGX
 && !(opts->x_ix86_isa_flags2_explicit & OPTION_MASK_ISA_SGX))
   opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA_SGX;

Please add vertical space here to visually separate flags and flags2 processing.

+if (processor_alias_table[i].flags2 & PTA2_RDPID
+&& !(opts->x_ix86_isa_flags2_explicit & OPTION_MASK_ISA_RDPID))
+  opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA_RDPID;

[patch][x86] -march=icelake

2017-11-11 Thread Koval, Julia 
Hi, this patch adds new option -march=icelake. Isasets defined in: 
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
I didn't add arch code to driver-i386.c, because there is no code available in 
SDM yet, only for cannonlake 
(https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
 Chapter 2).

gcc/
* config.gcc: Add -march=icelake.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect icelake.
* config/i386/i386-c.c (ix86_target_macros_internal): Handle icelake.
* config/i386/i386.c (processor_costs): Add m_ICELAKE.
(PTA_ICELAKE, PTA2_ICELAKE, PTA2_GFNI, PTA2_AVX512VBMI2, PTA2_VAES,
PTA2_AVX512VNNI, PTA2_VPCLMULQDQ, PTA2_RDPID, PTA2_AVX512BITALG): New.
(processor_target_table): Add icelake.
(ix86_option_override_internal): Add flags2 for new PTA, handle GFNI, 
RDPID.
(get_builtin_code_for_version): Handle icelake.
(M_INTEL_COREI7_ICELAKE): New.
* config/i386/i386.h (TARGET_ICELAKE, PROCESSOR_ICELAKE): New.
* doc/invoke.texi: Add -march=icelake.
gcc/testsuite/
* gcc.target/i386/funcspec-56.inc: Handle new march.
* g++.dg/ext/mv16.C: Ditto.
libgcc/
* config/i386/cpuinfo.h (processor_subtypes): Add INTEL_COREI7_ICELAKE.


0001-icelake.patch
Description: 0001-icelake.patch