public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: "Koval, Julia" <julia.koval@intel.com>
Cc: Uros Bizjak <ubizjak@gmail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
		Kirill Yukhin <kirill.yukhin@gmail.com>
Subject: Re: [patch][x86] -march=icelake
Date: Tue, 19 Dec 2017 13:08:00 -0000	[thread overview]
Message-ID: <CAFiYyc1ky1VzGeM4MYYkS+WgDOy8KTzLB83fjxmzgxHRzs3fbw@mail.gmail.com> (raw)
In-Reply-To: <4E89A029A0F8D443B436A5167BA3C53F8A461F0A@IRSMSX101.ger.corp.intel.com>

On Tue, Dec 19, 2017 at 1:34 PM, Koval, Julia <julia.koval@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 <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.

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

  reply	other threads:[~2017-12-19 13:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-12  7:33 Koval, Julia
2017-11-12 16:34 ` Uros Bizjak
2017-12-18 13:42   ` Koval, Julia
2017-12-19  8:31     ` Uros Bizjak
2017-12-19 11:55       ` Richard Biener
2017-12-19 12:34         ` Koval, Julia
2017-12-19 13:08           ` Richard Biener [this message]
2017-12-19 13:49           ` Jakub Jelinek
2018-01-22 11:46             ` Koval, Julia
2018-01-22 12:12               ` Jakub Jelinek
2018-01-22 15:10                 ` Koval, Julia
2018-01-24 11:05                   ` Uros Bizjak
2018-01-24 11:18                     ` Jakub Jelinek
2018-01-24 11:24                       ` Koval, Julia
2018-01-24 11:31                         ` Richard Biener
2018-01-30  8:53                           ` Koval, Julia
2018-01-30  9:56                             ` Jakub Jelinek
2018-01-30 12:55                               ` Koval, Julia
2018-02-01  7:49                                 ` Uros Bizjak
2018-02-01 14:02                                   ` Jakub Jelinek
2017-11-12 17:33 ` Sandra Loosemore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFiYyc1ky1VzGeM4MYYkS+WgDOy8KTzLB83fjxmzgxHRzs3fbw@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=julia.koval@intel.com \
    --cc=kirill.yukhin@gmail.com \
    --cc=ubizjak@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).