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