Bug 81161 - poor code concatenating bitfields
Summary: poor code concatenating bitfields
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 8.0
: P3 enhancement
Target Milestone: ---
Assignee: Andrew Pinski
URL:
Keywords: missed-optimization
Depends on: 18041
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-21 19:19 UTC by Nathan Sidwell
Modified: 2021-07-20 23:30 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-06-22 00:00:00


Attachments
example (117 bytes, text/plain)
2017-06-21 19:19 UTC, Nathan Sidwell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Sidwell 2017-06-21 19:19:41 UTC
Created attachment 41604 [details]
example

The example code is trying to use a set of adjacent single bit fields as a wider value.  (Think TREE_LANG_FLAG_{N,N+2} to explain why I can't just make a 3-bit bitfield).  We don't spot this is just extrating a wider bitfield[*]  here's the x86_64 code I get:
	movzbl	(%rdi), %edx
	movl	%edx, %eax
	movl	%edx, %ecx
	shrb	$2, %dl
	shrb	$4, %al
	shrb	$3, %cl
	andl	$1, %edx
	andl	$1, %eax
	andl	$1, %ecx
	sall	$2, %eax
	addl	%ecx, %ecx
	orl	%ecx, %eax
	orl	%edx, %eax
	ret

which is roughly doing:
   t1 = (val >> 2) & 1
   t2 = (val >> 3) & 1
   t3 = (val >> 4) & 1
   r = (t3 << 2) | (t2 + t1) | t1

optimal code would be something like:
   movzbl	(%rdi), %eax
   shrb $2,%al
   andl $7,%eax

this is similar to 68360, but looks sufficiently different to warrant a new report.

[*] where bitfield packing was from the other end of the object, one might want to swap the bitfields around to get a nice ordering.  Let's just assume little-endian packing for the sake of argument.
Comment 1 Andrew Pinski 2017-06-21 20:33:58 UTC
More like PR 18041.
Comment 2 Andrew Pinski 2017-06-21 20:34:34 UTC
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18041#c7 .
Comment 3 Nathan Sidwell 2017-06-21 22:11:40 UTC
similar but different.  Maybe same underlying optimization is needed.  I don't know.
Comment 4 Richard Biener 2017-06-22 09:24:19 UTC
Enhance gimple-ssa-store-merging.c to handle non-constants aka marry it with
the bswap pass (in tree-ssa-math-opts.c) which does the analysis (only
on byte granularity...) seeing that all values stem from shifting/oring
of parts of the same value.
Comment 5 Andrew Pinski 2021-07-20 23:30:52 UTC
Mine. But might not get until next year.