From: Andi Kleen <andi@firstfloor.org>
To: gcc-patches@gcc.gnu.org
Cc: Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT
Date: Fri, 20 May 2016 15:54:00 -0000 [thread overview]
Message-ID: <20160520155439.GU13997@two.firstfloor.org> (raw)
In-Reply-To: <alpine.DEB.2.20.1605201656560.1967@laptop-mg.saclay.inria.fr>
On Fri, May 20, 2016 at 05:11:59PM +0200, Marc Glisse wrote:
> On Fri, 20 May 2016, Andi Kleen wrote:
>
> >Richard Biener <rguenther@suse.de> writes:
> >
> >>The following patch adds BIT_FIELD_INSERT, an operation to
> >>facilitate doing bitfield inserts on registers (as opposed
> >>to currently where we'd have a BIT_FIELD_REF store).
> >
> >I wonder if these patches would make it easier to use the Haswell
> >bit manipulations instructions on x86 (which act on registers).
> >
> >I found that gcc makes significantly less use of them than LLVM,
> >sometimes leading to much bigger code.
>
> Could you point at some bugzilla entries? I don't really see which
> BMI* instruction could be helped by BIT_FIELD_INSERT (PDEP seems too
> hard). There is one BMI1 instruction we don't use much, bextr (only
> defined with an UNSPEC in i386.md, unlike the TBM version), but it
> is about extracting.
Ok. Yes I was thinking of BEXTR.
I thought I had filed a bugzilla at some point, but can't
find it right now. If you compare bitfield code
compiled for Haswell on LLVM and GCC it is very visible
how much worse gcc is.
So perhaps it only needs changes in the backend.
-Andi
next prev parent reply other threads:[~2016-05-20 15:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-13 10:51 Richard Biener
2016-05-16 0:55 ` Bill Schmidt
2016-05-16 12:37 ` Bill Schmidt
2016-05-17 7:52 ` Richard Biener
2016-05-16 8:24 ` Eric Botcazou
2016-05-17 7:50 ` Richard Biener
2016-05-17 8:13 ` Eric Botcazou
2016-05-17 15:19 ` Michael Matz
2016-05-19 13:23 ` Richard Biener
2016-05-19 15:21 ` Eric Botcazou
2016-05-20 8:59 ` Richard Biener
2016-05-20 11:25 ` Jakub Jelinek
2016-05-20 11:41 ` Richard Biener
2016-05-20 11:52 ` Jakub Jelinek
2016-05-20 11:53 ` Richard Biener
2016-05-20 14:11 ` Andi Kleen
2016-05-20 15:12 ` Marc Glisse
2016-05-20 15:54 ` Andi Kleen [this message]
2016-05-20 16:08 ` Jakub Jelinek
2016-05-20 19:25 ` Richard Biener
2016-05-20 17:08 ` Marc Glisse
2018-11-15 1:27 ` Andrew Pinski
2018-11-15 8:29 ` Richard Biener
2018-11-15 8:31 ` Richard Biener
2019-12-17 2:41 ` Andrew Pinski
2019-12-17 3:25 ` Andrew Pinski
2020-01-07 7:37 ` Richard Biener
2020-01-07 9:40 ` Andrew Pinski
2020-01-07 10:04 ` Richard Biener
2020-01-07 11:14 ` Richard Sandiford
2020-01-07 11:38 ` Richard Biener
2020-01-07 11:52 ` Richard Sandiford
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=20160520155439.GU13997@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=gcc-patches@gcc.gnu.org \
/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).