public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/96625] New: Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset
@ 2020-08-15 9:46 pskocik at gmail dot com
2020-08-16 19:31 ` [Bug middle-end/96625] " pinskia at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: pskocik at gmail dot com @ 2020-08-15 9:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96625
Bug ID: 96625
Summary: Unnecessarily large assembly generated when a
bit-offsetted higher-end end of a uint64_t-backed
bitfield is shifted toward the high end (left) by its
bit-offset
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
(Bitfields backed by 32-bit unsigneds are handled well.)
My example (https://gcc.godbolt.org/z/Yac38T):
#include <stdint.h>
#define FRONTSZ 3
#define UTYPE uint64_t
struct s{ union {
UTYPE whole;
struct {
UTYPE front:FRONTSZ,
tail:8*sizeof(UTYPE)-FRONTSZ; };
};};
UTYPE hiShifted_tail(struct s X) { return X.tail<<FRONTSZ; }
//better codegen:
UTYPE hiShifted_tail2(struct s X) { return X.whole>>FRONTSZ<<FRONTSZ; }
UTYPE hiShifted_tail3(struct s X) { return X.whole &
(0xffffffffffffffff<<FRONTSZ); }
x86-64 assembly generated for hiShifted_tail{,2,3}:
0000000000000000 <hiShifted_tail> (14 bytes):
0: 48 b8 f8 ff ff ff ff ff ff 1f movabs rax,0x1ffffffffffffff8
a: 48 21 f8 and rax,rdi
d: c3 ret
0000000000000000 <hiShifted_tail{2,3}> (8 bytes):
0: 48 89 f8 mov rax,rdi
3: 48 83 e0 f8 and rax,0xfffffffffffffff8
7: c3 ret
The codegen follows the same pattern for other front-sizes.
hiShifted_tail() on clang (regardless of whether uint64_t or uint32_t is used
as the backing type) and on gcc with uint32_t rather than uin64_t used as the
bitfield-backing-type follows the smaller codegen patter of
hiShifted_tail{2,3}.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/96625] Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset
2020-08-15 9:46 [Bug c/96625] New: Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset pskocik at gmail dot com
@ 2020-08-16 19:31 ` pinskia at gcc dot gnu.org
2020-08-17 7:19 ` crazylht at gmail dot com
2020-08-25 10:19 ` rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-08-16 19:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96625
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Keywords| |missed-optimization
Component|c |middle-end
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/96625] Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset
2020-08-15 9:46 [Bug c/96625] New: Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset pskocik at gmail dot com
2020-08-16 19:31 ` [Bug middle-end/96625] " pinskia at gcc dot gnu.org
@ 2020-08-17 7:19 ` crazylht at gmail dot com
2020-08-25 10:19 ` rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: crazylht at gmail dot com @ 2020-08-17 7:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96625
--- Comment #1 from Hongtao.liu <crazylht at gmail dot com> ---
movabs rax,0x1ffffffffffffff8 --- it also clear high 3 bits.
and rax,rdi
differs from
and rax,0xfffffffffffffff8
using g++ -O2 test.c -S got
---
movq %rdi, %rax
andq $-8, %rax
ret
---
but gcc -O2 test.c -S got
---
movabsq $2305843009213693944, %rax ---- (1FFFFFFFFFFFFFF8₁₆)
andq %rdi, %rax
ret
---
Is this related to language standard?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/96625] Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset
2020-08-15 9:46 [Bug c/96625] New: Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset pskocik at gmail dot com
2020-08-16 19:31 ` [Bug middle-end/96625] " pinskia at gcc dot gnu.org
2020-08-17 7:19 ` crazylht at gmail dot com
@ 2020-08-25 10:19 ` rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-08-25 10:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96625
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's no promotion on bitfields bigger than int, so yes, this would depend on
the frontends. The zeroing of the upper bits is done by RTL expansion for
bit-field arithmetic.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-08-25 10:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-15 9:46 [Bug c/96625] New: Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset pskocik at gmail dot com
2020-08-16 19:31 ` [Bug middle-end/96625] " pinskia at gcc dot gnu.org
2020-08-17 7:19 ` crazylht at gmail dot com
2020-08-25 10:19 ` rguenth at gcc dot gnu.org
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).