[patch][x86] -march=icelake

[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 <bitset> 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.guenther@gmail.com]
> Sent: Tuesday, December 19, 2017 12:56 PM
> To: Uros Bizjak <ubizjak@gmail.com>
> Cc: Koval, Julia <julia.koval@intel.com>; GCC Patches <gcc-
> patches@gcc.gnu.org>; Kirill Yukhin <kirill.yukhin@gmail.com>
> Subject: Re: [patch][x86] -march=icelake
> 
> On Tue, Dec 19, 2017 at 9:29 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> > On Mon, Dec 18, 2017 at 2:42 PM, Koval, Julia <julia.koval@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 <bitset>
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-icelake.patch_enums
Type: application/octet-stream
Size: 51097 bytes
Desc: 0001-icelake.patch_enums
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20171219/a71af43a/attachment.obj>