This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 20 May 2016 19:08:25 +0200 (CEST)
- Subject: Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1605131239490 dot 18037 at t29 dot fhfr dot qr> <87r3cwes8x dot fsf at tassilo dot jf dot intel dot com> <alpine dot DEB dot 2 dot 20 dot 1605201656560 dot 1967 at laptop-mg dot saclay dot inria dot fr> <20160520155439 dot GU13997 at two dot firstfloor dot org>
- Reply-to: gcc-patches at gcc dot gnu dot org
On Fri, 20 May 2016, Andi Kleen wrote:
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.
If I try some simple operations on bitfields, I don't see anything that
obvious.
movl $1285, %eax # imm = 0x505
bextrl %eax, %edi, %eax
vs
shrl $5, %eax
andl $31, %eax
is not that much better.
Incrementing a field gives one more shift with gcc and one more 'and' with
clang, so maybe clang is slightly better there.
So perhaps it only needs changes in the backend.
With -mtbm we generate
bextr $1285, %edi, %eax
so it shouldn't be hard to generate the same code as clang above, but I
don't think that's an example of the "much worse" you have in mind.
--
Marc Glisse