public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug middle-end/68360] GCC bitfield processing code is very inefficient [not found] <bug-68360-4@http.gcc.gnu.org/bugzilla/> @ 2021-12-22 9:52 ` pinskia at gcc dot gnu.org 2023-07-16 14:39 ` tkoenig at gcc dot gnu.org 2023-07-16 17:15 ` pinskia at gcc dot gnu.org 2 siblings, 0 replies; 3+ messages in thread From: pinskia at gcc dot gnu.org @ 2021-12-22 9:52 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Mine for GCC 13. ^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/68360] GCC bitfield processing code is very inefficient [not found] <bug-68360-4@http.gcc.gnu.org/bugzilla/> 2021-12-22 9:52 ` [Bug middle-end/68360] GCC bitfield processing code is very inefficient pinskia at gcc dot gnu.org @ 2023-07-16 14:39 ` tkoenig at gcc dot gnu.org 2023-07-16 17:15 ` pinskia at gcc dot gnu.org 2 siblings, 0 replies; 3+ messages in thread From: tkoenig at gcc dot gnu.org @ 2023-07-16 14:39 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 Thomas Koenig <tkoenig at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2015-11-16 00:00:00 |2023-7-16 CC| |tkoenig at gcc dot gnu.org --- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- Just stumbled across this. A maybe simpler testcase: typedef struct { unsigned long x: 42; unsigned b: 1; unsigned long y: 42; } myfield; typedef struct { unsigned long x: 7; unsigned b: 1; unsigned long y: 42; } yourfield; void foo(myfield *x) { x->b = 1; } void bar (yourfield *x) { x->b = 1; } gets, on RISC-V, foo: ld a5,0(a0) li a4,1 slli a4,a4,42 or a5,a5,a4 sd a5,0(a0) ret bar: ld a5,0(a0) ori a5,a5,128 sd a5,0(a0) ret Using an indexed load byte/store byte would be an advantage for foo, at least. ^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/68360] GCC bitfield processing code is very inefficient [not found] <bug-68360-4@http.gcc.gnu.org/bugzilla/> 2021-12-22 9:52 ` [Bug middle-end/68360] GCC bitfield processing code is very inefficient pinskia at gcc dot gnu.org 2023-07-16 14:39 ` tkoenig at gcc dot gnu.org @ 2023-07-16 17:15 ` pinskia at gcc dot gnu.org 2 siblings, 0 replies; 3+ messages in thread From: pinskia at gcc dot gnu.org @ 2023-07-16 17:15 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=107601 --- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Thomas Koenig from comment #7) > Using an indexed load byte/store byte would be an advantage for foo, at > least. That would be more related to PR 107601 and less to do with this issue. Since for riscv SLOW_BYTE_ACCESS is set, then all bitfields accesses are widen. But then you want to have them widen normally; otherwise you get other bad code generation ... Note riscv with zbs in the testcase in comment #7 will be one bseti: ld a5,0(a0) bseti a5,a5,42 sd a5,0(a0) So it is less of an issue ... ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-07-16 17:15 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bug-68360-4@http.gcc.gnu.org/bugzilla/> 2021-12-22 9:52 ` [Bug middle-end/68360] GCC bitfield processing code is very inefficient pinskia at gcc dot gnu.org 2023-07-16 14:39 ` tkoenig at gcc dot gnu.org 2023-07-16 17:15 ` pinskia 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).